Introduction
What Solieum is, what it is not, and the four components plus one habit that the design rests on.
What Solieum is
Solieum is an optimistic rollup that settles to Solana.
Transactions are executed off-chain by a sequencer in a Solana Virtual Machine environment. The transactions are compressed and published on Solana, so anyone can rebuild the chain from scratch. The state that results is committed to a Solana program as a single 32-byte root, under a bond. That root becomes final only after a challenge window passes without anyone proving it wrong, and a dispute is resolved by Solana itself rather than by a committee.
"Optimistic" names the default: a proposed root is assumed correct unless challenged. It is the assumption that buys the cheap execution, and the challenge window is what the assumption costs.
What Solieum is not
- Not a sidechain. There is no Solieum validator set deciding state or finality. Ordering is decided by a sequencer, and a staked sequencer set is a planned stage, but a sequencer set decides ordering only. Finality stays with Solana. An earlier version of this documentation described a proof-of-stake validator set with a one-SOL stake. That design was rejected: a validator set that decides state would make Solana decoration rather than security.
- Not a validium. Batch data is published on Solana, not to an external availability layer. A cheaper external layer would become a second trust root, and "secured by Solana" would stop being true without a footnote. Per-market validium is pre-authorised as an exception and would be disclosed on the front page of any affected market, never silently.
- Not a new virtual machine. Solieum forks Agave's SVM rather than reimplementing it, because bug-for-bug compatibility is the product promise and divergence is the one risk that cannot be bounded. The fork's determinism is enforced by a harness that replays identical blocks on different machines and compares roots byte for byte.
- Not audited, and not holding anyone's money. See Status and Roadmap.
The four components, and the fifth thing
Four components carry the design. A fifth thing, which is not a component at all, is what makes the other four worth anything.
The sequencer decides the order transactions execute in, seals a block every two seconds when there is work, and signs a receipt for each accepted transaction that fixes its batch and position before execution. That receipt is the accountability: two receipts assigning the same position to different transactions are a contradiction anyone holding both can prove, and the proof takes the sequencer's bond.
Data availability publishes each batch, compressed, in Solana transactions, committed so that any chunk can be proven to belong to the batch a given state root refers to. A batch is opened with its commitment, its chunks are posted, and sealing succeeds only if the published bytes fold to the commitment declared at open.
Settlement is the Solana program that holds the sequence of state roots. A root finalizes only if its parent is final and its own window has elapsed unchallenged. Withdrawals verify against final roots only.
The dispute game turns a disagreement about a batch into a disagreement about one instruction. Challenger and proposer bisect the execution trace, each round halving the disputed range, until the disagreement is a single step. Solana then verifies that step directly from Merkle proofs of the accounts it touched, and the loser forfeits a bond.
What a dispute is actually about is worth stating early, because this is where most rollup descriptions go vague. It is not a block. It is a trace: a sequence of state commitments, one per step, where a step is the fee leaving a payer, one instruction of a successful transaction, a withdrawal, or a deposit credit. The root's commitment to those steps is itself a tree, so an instruction can be proven to belong to the batch a root refers to, and each step's leaf either carries a value a verifier can recompute or is marked opaque under a domain no verifier knows. Which steps are which is published per block rather than discovered mid-dispute, and that boundary is the honest definition of what "fraud proof" covers on this chain today.
The fifth thing is independent verification. Fraud proofs protect nobody unless somebody runs a verifier and checks. If fraud never happens, nobody is paid for watching, and the rational choice is to stop watching, which is exactly when attempting fraud becomes worthwhile. Solieum treats verification as infrastructure to fund rather than goodwill to hope for. The watchtower runs as one command today. Nobody outside the operator runs one yet, and that gap is named rather than glossed.
What a user actually experiences
| Confirmation | A signed receipt at admission, then a sealed block within about two seconds |
| Root on Solana | Median 5.5 seconds from block to committed root, measured over 64 blocks on devnet |
| Fee | A flat 5,000 lamports, paid in SOL, on the devnet chain |
| Deposit | Dominated by Solana's own confirmation, well under a minute |
| Withdrawal, canonical | The challenge window plus the air gap, about three days by the mainnet design |
| Withdrawal, fast exit | Minutes, at a spread, from a liquidity provider fronting the funds |
Every one of those figures is measured or is a named constant. What each of them hides is in the pages that follow.
Compatibility
Solieum executes real Solana transactions. The node accepts a wallet's own wire format, which is why the bridge application needs nothing from a wallet beyond the ability to sign a transaction. A program compiled for Solana runs on a Solieum chain unchanged: the counter example in the repository was compiled by a third-party toolchain to a native Solana program, built with the standard SBF toolchain, and registered on a local Solieum chain without editing the program or its instruction encoding.
Compatibility is a matrix, not an adjective. The surfaces where a rollup necessarily differs from its base layer, clock semantics, rent, fee accounting, are pinned explicitly and documented as they are measured, rather than covered by a claim of being one hundred percent compatible.
Use cases the design is aimed at
These are workloads where base-layer economics bite first: high transaction counts, low value per transaction, and users who notice latency. Payments and micropayments, on-chain order flow and market structure that needs a stated ordering policy, games with frequent small state changes, and social applications where a single interaction has to cost a negligible amount.
Nothing listed here is live. The chain settles to Solana devnet with no public endpoint. This is what it is being built for, not what is running on it.