Compatibility

SVM compatibility, honestly

Every divergence from Solana named, with what to do about it. "100% compatible" is not true of any Layer 2.

"100% compatible, no changes needed" is not true of any Layer 2, and repeating it costs developers days of debugging. Below is the shape of the compatibility matrix Solieum publishes instead: every divergence named, with what to do about it.

  • IdenticalBehaves exactly as on Solana.
  • RedefinedExists, with L2 semantics you need to know.
  • UnavailableNot present. Code depending on it must change.
AreaStatusWhat it means for your program
Account modelidenticalAccounts, ownership, PDAs, and rent-exemption work as they do on Solana.
Program model / CPIidenticalPrograms, instructions, and cross-program invocation are unchanged.
Ed25519 signaturesidenticalSame signing and verification.
Clock — slot and epochredefinedL2 slots advance on the L2's cadence, not Solana's. Anything deriving timing from slot numbers needs review.
Clock — unix timestampredefinedSet by the sequencer within bounds enforced at settlement. Do not treat as a trusted oracle.
SlotHashes / recent blockhashesredefinedRefers 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 accountingredefinedPaid in SOL; no token. Today a flat 5,000 lamports per transaction, burned up to block 100 on the beta chain and kept by the operator from that block on (ADR-0017; crossed 2026-09-10) — and either way it does not cover settlement: a block needs about 820 such fees to pay for its own root and batch on Solana. The target model adds data-availability and settlement components, so bytes cost as well as compute. Priority-fee instructions are not honoured.
Rent economicsredefinedRent-exemption thresholds follow L2 storage costs, not Solana's.
Compute budgetredefinedLimits are set for L2 conditions and may differ per instruction and per block.
Stake / vote programsunavailableSolieum does not run Solana's validator consensus, and will not — finality is Solana's. Programs touching stake accounts must change.
Address lookup tablesunavailableVersioned transactions carrying lookup tables are rejected at admission rather than resolved against the wrong accounts. Use legacy transactions.
Direct L1 state readsunavailableL2 programs cannot read Solana account state synchronously. Use the bridge messaging path.

This matrix is illustrative of the format and will be replaced with a version verified against a specific release, stating the release. Compatibility claims that do not name a version are not claims. The first observed rows — from replaying recorded mainnet transactions — are below.

Observed so far

These rows come from replaying recorded Solana mainnet-beta transactions on the settlement team's fork of the SVM runtime (the in-process execution harness in the protocol repository, replay mode). Fixtures: twelve finalized mainnet transactions fetched 2026-08-23 and 2026-08-24 UTC (slots 441205057–441416882), committed with full provenance alongside 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. The last row is different in kind: a single observation on the devnet chain itself, 2026-09-02.

SurfaceObserved behaviour
System program transfersFive recorded transactions (nine instructions): every post-balance byte-exact against what mainnet recorded. Each transaction replayed twice on independent runtimes with identical resulting state roots.
Memo v2 — the mainnet program binaryThree recorded 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 transfersFour recorded transactions (five Transfer/TransferChecked instructions), token accounts and mints reconstructed from the recorded balance metadata: every token amount and every lamport balance identical to what mainnet recorded. Deterministic across independent replays. One finding surfaced by the load probe: the current mainnet Token binary requires a syscall (sol_get_sysvar) newer than the 1.18-era runtime fork, so these replays run SPL Token built from its published v3.5.0 source with the same era toolchain — provenance one class weaker than bytes-from-mainnet, and stated as such.
Wallet-format transactions, on devnetA 215-byte bincode Transaction built exactly as a wallet builds one — recent blockhash, ed25519 signature, system transfer — was accepted by the devnet node, executed, and its block's root committed to Solana devnet within five seconds. An identical resend was refused as already processed, which is Solana's exact semantics. One transaction, one observation; the shape works, the volume is not yet measured.

These rows cover what public RPC data lets us 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 yet the per-release matrix above, which requires replaying arbitrary stateful programs against captured account data.

Migration

Migration checklist

The practical sequence for bringing an existing Solana program over, ordered so the expensive discoveries happen early.

  1. 01

    Grep for the divergent surfaces

    Clock, SlotHashes, rent maths, stake or vote accounts, and anything reading L1 state. The matrix above is the grep list. No hits: your migration is mostly configuration.

  2. 02

    Re-examine every timing assumption

    Slot arithmetic, expiry windows, auction durations. Convert anything meaning wall-clock time to timestamps, and treat the timestamp as sequencer-set within bounds — not an oracle.

  3. 03

    Re-run the economics

    Fees price bytes as well as compute here. Instruction layouts that were harmlessly verbose on L1 become a measurable cost at volume.

  4. 04

    Port the tests, then add the L2 cases

    Existing suites should pass near-unchanged for identical surfaces — that is the compatibility claim, tested. Add cases for confirmation levels and the withdrawal path.

  5. 05

    Stage on testnet against the matrix

    Run the real workload and diff behaviour against L1, line by line, before any value moves. File every divergence the matrix did not predict — each one is either our documentation bug or our compatibility bug, and we want it.

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.