01Technology
How Solieum works
Execution off-chain, settlement on Solana. This page walks the full path a transaction takes, and names what has to be true at each step for the result to be trustworthy. Stages 1 to 4 run on Solana devnet today; the stage-5 bridge credits deposits there — a deposit on Solana lands on the L2 in the next block — and nobody outside the team has exercised an exit yet.
How a transaction settles
- 01
Submit
Transactions arrive at the node's RPC in Solana's own wire format — the same bytes a wallet sends to any cluster — and pass signature, blockhash and duplicate checks. Then the node executes each one against the block being filled, in the position it would occupy: one that would fail is refused there, with the program's own reason and no fee, rather than admitted and later dropped. Signing and account model are unchanged.
- 02
Order and execute
The sequencer orders transactions first-come, first-served by admission, signs a receipt fixing each position before executing anything, then executes them against SVM state. That receipt is the soft confirmation — fast, and revocable until the batch settles.
- 03
Publish data
Batches are compressed and published in Solana transactions through the data-availability program: opened, posted, and sealed only if the bytes fold to the declared commitment. Live on devnet. Without published data there is no Layer 2 — only a promise.
- 04
Commit and challenge
A bonded proposer commits the state root to Solana. During the 48-hour challenge window any independent verifier can dispute an invalid root and take the bond. Live on devnet: block 1's root was committed under bond within five seconds of its transaction on the alpha chain (2026-09-02) and within the minute on the beta chain (2026-09-05). Since beta, the settlement program's dispute authority is the dispute game's enforcer — it is on gamma today — so a won game removes a root; no dispute has yet been played on devnet.
- 05
Settle or exit
After the window the root is final and withdrawals complete against the bridge program's vault. If the sequencer stops, users exit directly against the last final root — no operator cooperation required. Built and proven in the harness; the bridge vault is deployed and initialized on devnet, not yet exercised by anyone outside the team.
◆Failure modes
What can go wrong at each stage
A pipeline is only understood when you know how it fails. Each stage below names its failure, who notices, and what limits the damage.
- 01
Submission fails
The RPC node is down or refuses you. Damage: inconvenience, not loss — nothing has been signed away. Route around it with another RPC, or with forced inclusion through Solana if the refusal is deliberate.
- 02
The sequencer misbehaves
It can reorder you, delay you, or drop you. It cannot spend your funds or forge your signature. A dropped transaction never happened as far as the chain is concerned; a delayed one is bounded by the forced-inclusion window — and ignoring a forced entry past its deadline costs the operator the fee and faults its chain.
- 03
Data is withheld
Batches execute but the data behind them is not published. This is the quiet failure that disables everything downstream — nobody outside can verify, challenge, or exit. It is why data availability gets its own page and its own alarms: the verifier loop reports withheld data as not-yet-derivable, deliberately distinct from fraud, so nobody is accused on the strength of silence.
- 04
A bad root is committed
The proposer commits a state root that does not match honest execution. Any verifier that re-derived the state can see the mismatch and open a challenge; the dispute narrows to one instruction and the bad root is removed, taking the proposer's bond with it. On devnet the settlement program accepts that verdict only from the dispute program, by cross-program call.
- 05
Settlement stalls
Solana congestion or operator failure delays root submission. Funds are not at risk — the last final root still stands and exits against it still work. What degrades is latency: the node queues unsettled blocks and retries the same block in order, because the settlement program requires each root to chain onto the head it holds. A retry resumes from what Solana already recorded — the chunk after the last one the batch account holds, or only the root if the batch is already sealed — so a failed publish is never re-opened into a permanent stall or re-published into a duplicate. Roots past their window are finalized by the node, and by anyone: finalizing is permissionless. A blip costs time, not the chain. Tested against the real programs in-process, and exercised on devnet since: every one of the beta chain's 158 roots passed its window and was finalized, the first on 2026-09-06 and the last before it stopped on 2026-09-12, and gamma's roots are finalizing the same way.
How to read the rest of this site
Each stage above has a page that goes deeper: the sequencer's powers and limits, the data availability guarantee, the proof system's arithmetic, and the exit paths that work when everything else does not. If you read only one, read the exits page — it is the one that describes what happens when trust runs out.
Built for applications the base layer squeezes
A transaction that would fail is refused, free
On a typical day, a quarter to a third of the non-vote transactions Solana executes fail, and every one of them pays its fee. Solieum executes yours when you submit it, against the position it will occupy, and refuses the ones that would fail — with the program's own error, in milliseconds, for nothing. On-chain failures are zero by construction, forced-inclusion entries excepted.
Headroom for high-frequency apps
Order books, game state, and social feeds generate transaction volume that competes badly for L1 blockspace. Solieum executes them off the base layer, so they are not bidding against every launch on the chain — an execution lane priced per workload is the target beyond that, and is not built.
Fees paid in SOL, with the model still to come
Batching amortises settlement cost across the transactions in a block, which is what makes a low per-action fee reachable. Reachable, not reached: the devnet chain charges a flat 5,000 lamports today, the same as the base layer, and the fee model that changes it is on the roadmap. Fees are paid in SOL; no token is required.
SVM execution
Programs target the Solana Virtual Machine. A published compatibility matrix documents every divergence — sysvars, rent, and fee accounting differ on any L2, and pretending otherwise costs developers days.
Independent verifiability
Batch data is published in Solana transactions so any party can re-derive state and check the operator — live on devnet. Run a verifier yourself; the network is safest when its operators are not the only ones watching.
Permissionless exit
Withdrawal does not depend on the sequencer being cooperative, online, or willing. That property is what separates a Layer 2 from a service holding your funds.
Solve and the SDK
Write programs in Solve, Solieum's main framework: one CradleScript source, checked for common vulnerabilities when it builds and compiled to a native Solana program. Send transactions with the Solana client tooling you already use — the node accepts a wallet's own wire format.
Building something the base layer can't hold?
Tell us the workload. If Solieum is the wrong answer for it, we would rather say so early than have you find out at launch.