SVM Compatibility
Where Solieum behaves exactly like Solana, where it is redefined, and where something is simply absent, with the replay evidence behind each claim.
"One hundred percent compatible, no changes needed" is not true of any Layer 2, and repeating it costs developers days of debugging. This page is the shape of the matrix Solieum publishes instead: every divergence named, with what to do about it.
How Solieum executes
Solieum forks Agave's SVM rather than reimplementing it. Bug-for-bug compatibility is the product promise the matrix depends on, and divergence is the one risk that cannot be bounded. The costs accepted with that choice are an upstream tracking treadmill and a wrapping layer that pins every divergent surface explicitly.
The fork was confirmed by a spike before it was built on: a deployed Solana program executes in-process on the forked runtime with no validator, no RPC and no wall clock, and two independent executions from identical genesis produce byte-identical state roots, at 14,583 compute units for the instruction measured.
The matrix
| Area | State | What it means |
| Account model | Identical | Accounts, ownership, program-derived addresses and rent exemption work as they do on Solana |
| Program model and cross-program invocation | Identical | Programs, instructions and CPI are unchanged |
| Ed25519 signatures | Identical | Same signing and verification |
| Clock, slot and epoch | Redefined | L2 slots advance on the L2's cadence, not Solana's. Anything deriving timing from slot numbers needs review |
| Clock, unix timestamp | Redefined | Set by the sequencer within bounds enforced at settlement. Not a trusted oracle |
| Slot hashes and recent blockhashes | Redefined | Refers to L2 history: a 150-block window of L2 blockhashes, the same replay guard wallets already understand. Anything using it as a randomness source was already unsafe and is more so here |
| Fee accounting | Redefined | Paid in SOL, no token. A flat 5,000 lamports today. Priority-fee instructions are not honoured |
| Rent economics | Redefined | Rent-exemption thresholds follow L2 storage costs, not Solana's |
| Compute budget | Redefined | Limits are set for L2 conditions and may differ per instruction and per block |
| Stake and vote programs | Unavailable | Solieum does not run Solana's validator consensus and will not. Finality is Solana's. Programs touching stake accounts must change |
| Address lookup tables | Unavailable | Versioned transactions carrying lookup tables are rejected at admission rather than resolved against the wrong accounts. Use legacy transactions |
| Direct Layer 1 state reads | Unavailable | L2 programs cannot read Solana account state synchronously. Use the bridge path |
One behaviour has no row because it is not a divergence in a primitive, it is a different rule: a transaction that would fail is refused at submission rather than included and charged. See Technical Architecture.
This matrix names no release, so it is illustrative of the format rather than final. It will be replaced with a version verified against a specific release, stating that release. Compatibility claims that do not name a version are not claims.
What has actually been replayed
These rows come from replaying recorded Solana mainnet transactions on the forked runtime, in the protocol repository's in-process harness. The fixtures are twelve finalized mainnet transactions fetched on 23 and 24 August 2026, from slots 441,205,057 to 441,416,882, committed with full provenance beside the harness.
The harness charges no fee, so the fee payer's balance is compared after adding the recorded fee back. Every other account must match mainnet exactly.
| Area | Result |
| System program transfers | Five transactions, nine instructions: every post-balance byte-exact against what mainnet recorded. Each replayed twice on independent runtimes with identical resulting state roots |
| Memo v2, the mainnet program binary | Three transactions, eight instructions, executing the ELF fetched from the mainnet program account itself: program log lines and all balances identical to mainnet, deterministic across independent replays |
| SPL Token transfers | Four transactions, five transfer instructions, token accounts and mints reconstructed from recorded balance metadata: every token amount and every lamport balance identical to mainnet, deterministic across replays |
| Wallet-format transaction, on devnet | A 215-byte transaction built exactly as a wallet builds one, with a recent blockhash and an Ed25519 signature, was accepted by the node, executed, and its block's root committed to Solana within five seconds. An identical resend was refused as already processed, which is Solana's exact semantics |
One finding worth carrying forward. The current mainnet SPL Token binary requires a syscall newer than the 1.18-era runtime fork, so those replays run SPL Token built from its published v3.5.0 source with the same-era toolchain. That is provenance one class weaker than bytes-from-mainnet, and it is stated as such rather than rounded up.
What these rows do not cover. They cover what public RPC data lets anyone reconstruct exactly: transactions whose pre-state is determined by lamports and recorded token-balance metadata, plus program binaries where obtainable. They are evidence that the runtime fork executes real mainnet transactions faithfully. They are not the per-release matrix above, which requires replaying arbitrary stateful programs against captured account data. The devnet row is a single observation: the shape works, the volume is not measured.
Programs on a Solieum chain
A program compiled for Solana runs unchanged. Demonstrated on 5 September 2026 with a counter contract written in CradleScript, the language of Solieum's main framework Solve, compiled by its Cradle toolchain to a native Solana program, built with the standard SBF toolchain, and driven through a seven-step conformance scenario without editing the program, its instruction encoding, or anything in the client but the transport. All seven steps passed and every block settled.
Two caveats belong with that result, and both are on Technical Architecture in full:
- Programs are registered at node start today, not deployed by a transaction.
- A step through a registered program is opaque to the dispute game, and the node says so rather than letting it be assumed. Running third-party programs and defending every step of them in a dispute are two different maturity levels.