Solieum Programme Kit (SPK)
What a developer can actually use today: the node's RPC surface, the command line, the one behaviour that will surprise you, and what does not exist.
Start with what is not here
There is no published Solieum SDK. There is no @solieum/web3.js, no @solieum/sdk, no @solieum/bridge-sdk, and no solieum-rs crate. Earlier versions of this page documented all of them, with installation commands and code samples. None of it existed.
There is also no public RPC endpoint today, no hosted explorer, and no faucet. The chain runs on Solana devnet and its node is not open to the internet.
What follows is what does exist.
You do not need a Solieum SDK
The Layer 2 accepts real Solana wire transactions, and the node answers Solana-shaped JSON-RPC. A client written against Solana works with the endpoint swapped, and a wallet needs nothing beyond signTransaction, which is why the bridge application never calls signAndSendTransaction.
That is a deliberate property rather than a convenience. It is what makes the compatibility claim checkable: a program compiled for Solana runs unchanged, a transaction signed for Solana verifies unchanged, and a key that holds SOL on Solana holds bridged SOL on the Layer 2 at the same address. The divergences that do exist are enumerated in SVM Compatibility rather than left to be discovered.
The Solana-shaped methods
Account info, balances, the latest blockhash, slot, blocks, transactions, signature statuses, and signatures for an address. Enough to read state, build a transaction, send it and follow it.
The methods that are Solieum's own
These have no Solana equivalent, because they describe things Solana does not have.
| Method | What it answers |
| getChainInfo | Chain id, genesis hash, head, and which programs are registered |
| getSettlement | Every root, its status, its window, the finalized head, and each block's settlement cost |
| getReceipt, getReceipts, getSequencerReceipts | The signed ordering receipt that fixes a transaction's position before execution |
| getForcedQueue, getForcedEntry | The forced-inclusion queue, an entry's deadline, and its inclusion state |
| getDeposits, getBridge, getWithdrawal | Bridge state, read live from the portal on Solana |
| getWithdrawals | The Layer 2 leaf list |
| getWithdrawalProof | The inclusion proof a withdrawal needs, against the right root, ready to present on Solana |
| getSequencerBond | The bond behind the receipt-signing key, read from the settlement cluster on every call |
| getBlockPayload | The published bytes of a block, so a client can re-derive rather than trust |
| getBatchDetail, getBlockDetail, getTransactionDetail, getAddressDetail | Explorer-grade views |
| getDropped, getPending | What was refused and what is queued |
| getPrograms | Registered programs, with byte length and hash, and the caveat that these are not a proof |
| getStats, getTimeSeries, getTopAccounts, getTransfersForAddress | Chain metrics and address activity |
One trap worth publishing. getWithdrawals is the Layer 2 leaf list that the fast-exit loop polls. It is deliberately kept off the Layer 1 readers, so it never carries a paid flag. To learn whether a withdrawal has actually been paid, ask getBridge or getWithdrawal, which read the portal record live. Judging payout state from the leaf list gives the wrong answer.
The command line
solieum-node is the node and the operator's tool in one binary. The subcommands that matter to someone evaluating the system rather than running it:
| Command | What it does |
| verify --watch | The watchtower: re-derive the chain from Solana through independent readers that must agree, check every new batch, check bridged supply against the vault, alarm on divergence, and open a challenge under bond if the divergence is real |
| verify --archive | Re-derive from a node's own append-only block log when a pruned endpoint no longer carries the chunks. The archive is not trusted: its bytes are decoded, its deposits matched against inbox entries read under quorum, and replayed to a root that must equal the one on chain |
| portal --deposit | Lock lamports and enqueue the credit, without a browser |
| withdraw-l1 --prove, --finalize | The two Layer 1 halves of an exit. Both are permissionless: the node ships them as a convenience over instructions anyone can send |
| bond, slash | Register a sequencer bond, or prove an equivocation against one. slash judges locally with the protocol's own function first, so a pair that is not equivocation costs nothing to try |
| fees | Print the flat fee beside the composed one, with the data, settlement and margin shares broken out |
| finalize | Run one finalization pass, closing roots whose retention has elapsed where that is deployed |
One sharp edge: genesis --help is not help. It writes a genesis file into the working directory.
Running a program on a Solieum chain
The node registers programs at start, one flag per program, mapping an address to a compiled .so file. getChainInfo then reports what it loaded, together with the caveat: a step through a registered program is opaque to the dispute game. That is a convenience for a local chain, not a defended property, and the node prints it rather than letting it be assumed.
Two consequences a developer should hold onto:
- The program set is part of the state transition. A data directory replays only under the same set, and nothing the chain publishes says what that set was, so an independent verifier has to be told out of band. That gap is described in full in Technical Architecture and is the reason an explorer can only publish the node's own statement about a file on the operator's disk.
- Program deployment by transaction does not exist yet. Registration at node start is the current mechanism.
Two worked examples ship in the repository: an SPL-token scenario on a local chain, and a counter program written in CradleScript, compiled by Solve's Cradle toolchain and run without edits. See Solve Framework.
One behaviour that will surprise you
A transaction that would fail is refused at submission, not included and charged.
Execution happens at admission. If your instruction returns an error, you get the program's own error and logs back at submit time, and nothing enters a block: no fee, no position, no receipt, no published bytes, no drop record.
This is not a nicety. On a self-taken sample of 39 finalized Solana mainnet blocks in one hour on 15 September 2026, 15,459 non-vote transactions carried 4,100 failures, every one of which paid its fee: 26.5 percent, buying nothing. That is the necessary consequence of an open fee market, where you build against state you can see and an unknown leader executes later against state that exists then. Solieum has one executor and fixes your position before executing, so it can know the outcome in advance, and refusing is strictly better for you than charging.
What it means in practice: simulate-then-send is not a pattern you need here, and a successful submission is a guarantee rather than a forecast.
In the counter example, two deliberate failures, an underpaid call and a call from the wrong owner, came back as the program's own custom errors, and every transaction in the surrounding blocks succeeded.
What a developer should wait for
- A public endpoint, and the chain identity to point a client at.
- Published client packages, when there is a network worth pointing them at.
- A hosted explorer and a faucet.
- Program deployment on the public chains rather than registration at node start.
- The program set committed to the chain, so a verifier need not be told it.
- Wider one-step classes, so a step through an arbitrary program is defensible in a dispute rather than opaque.
Each of those is a real gap, and this page would rather name them than paper over them with an install command for a package that does not exist.