Solana Layer 2

Scaling Solana withouthanding over the keys.

Solieum is an optimistic rollup: it executes transactions off-chain and settles them on Solana. More throughput and lower fees for applications that outgrow the base layer — with the trust model written down, not buried.

StatusPre-mainnet. The gamma devnet chain has been live since 2026-09-11: five programs carrying settlement plus the sequencer bond, a 48-hour challenge window, the dispute game's enforcer as the settlement program's dispute authority, and account data committed by root. The beta chain it succeeded ran from 2026-09-05 to 2026-09-12 and stopped with all 158 of its roots final, four withdrawals paid and nothing owed. The node settles real blocks to Solana, checkable from its public RPC. No public endpoint yet.

02Technology

How a transaction settles

  1. 01

    Submit

  2. 02

    Order and execute

  3. 03

    Publish data

  4. 04

    Commit and challenge

  5. 05

    Settle or exit

settlement cyclebatch #4821
L2 batch0/12
state rootcomputing…
Solana L1
waiting
Committed is not final. Finality is the end of the challenge window — the point at which a withdrawal can complete.

Full walkthrough of each stage →

03Capabilities

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.

04Security

What you are trusting, stated plainly

Solieum is an optimistic rollup on Solana: batch data and state roots live on Solana, and that is not changing — no sidechain, no validator set of our own deciding finality. A Layer 2 inherits the base layer's security only under specific conditions. Here is where Solieum stands against each one today. This table changes as the network matures, and every change is announced.

  • Bridge custody

    In progress

    Withdrawals are proven against a final state root by the bridge program; no signer set releases funds. Between the proof and the payout there is an air gap in which a guardian can deny a settlement root — a root, never a named withdrawal, and an affected claim is reopened by anyone and proven again against a later root. The program is deployed and initialized on devnet at its pinned id, with a one-hour payout delay (mainnet: twenty-four hours); a deposit is a forced-inclusion entry the node credits at the next block, and the first devnet deposit was credited end to end on 2026-09-02. Upgrade authority is a single operator key: the multisig, threshold and timelock that will hold it are to be published before mainnet.

  • Proof system

    In progress

    Interactive bisection to a single instruction, then a witnessed one-step verifier for system and SPL-token transfers, fees, deposit credits, withdrawals, and the steps that create or empty an account — about 20,000 compute units per transfer step, measured in the test harness. The dispute program is deployed on devnet, and on the gamma chain, as on beta before it, its verdict is what settles a challenge. It enforces nowhere that holds real funds yet, because nowhere does.

  • Data availability

    In progress

    Every batch is published in Solana transactions through the data-availability program and bound to its commitment; sealing fails if the bytes do not match. Live on devnet. Retrieval beyond Solana's own history is the open item: an archive service and its retention period are to be published before mainnet.

  • Forced inclusion

    In progress

    Submit directly to L1 when the sequencer will not include you. The inbox program is deployed on devnet and the node drains it every block; an ignored entry costs the operator the fee and faults its chain. This is what makes a single sequencer acceptable. Not yet exercised by anyone outside the team.

The complete trust model →

06Roadmap

The order things have to happen in

Decentralisation is a sequence, not a switch. Each stage below has a condition that has to be true before we claim it — no stage is announced before it can be verified from the outside. The system class is fixed: an optimistic rollup on Solana. Decentralisation goes into who sequences, never into who decides finality.

  1. 01

    Devnet

    Live
  2. 02

    Testnet

    In progress
  3. 03

    Mainnet beta

    Planned
  4. 04

    Fast exits, team-fronted

    Planned
  5. 05

    Proofs enforcing

    Planned
  6. 06

    Fast exits, underwritten

    Planned
  7. 07

    Staked sequencer set

    Planned
  8. 08

    Reduced trust

    Planned
  9. 09

    Ephemeral lanes

    Planned

What has to be true before each stage is claimed →

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.