Bridge

Moving assets between layers

How value crosses between Solana and Solieum — the flows, the invariant that cannot break, and the custody model as it stands today.

The bridge is where value crosses between Solana and Solieum, and it is the highest-consequence component in any Layer 2. Most large losses in this category have come from bridge contracts and operator keys — so this page states the mechanism, what is deployed where, and the current custody model rather than only the happy path.

Open the bridge at walletbridge.org → Devnet only. It verifies the deployed portal against a pinned hash of the committed build before it will sign anything, and shows every account and every byte of a transaction before your wallet does.

Solana → Solieum

In progress
  1. 01

    Lock

    Assets are transferred into a vault account the bridge program owns on Solana. Nothing is credited until the lock is confirmed.

  2. 02

    Confirm

    The deposit waits for Solana finality, so a reorganisation cannot undo it. This wait is a safety property, not latency to be optimised away.

  3. 03

    Credit

    A matching balance becomes spendable on Solieum, backed one-to-one by the locked assets. Each deposit carries a sequence-derived id, so the same deposit can never be credited twice.

Deposit time is dominated by the confirmation wait, which is Solana finality — well under a minute. A deposit is a forced-inclusion entry: the bridge program locks the amount and, in the same instruction, enqueues a deposit record on the forced-inclusion queue, signed by a relay account only the program can sign for — so the deadline, the fault for skipping it, and the public bytes that forced transactions have apply to deposits too, and a deposit the sequencer never includes can be refunded from the vault by anyone once its deadline passes. Exercised in the test harness against the real inbox program, then on devnet. On the gamma chain, whose portal is deployed, initialized and guardian-installed, deposits are credited end to end: an enqueued entry is credited to the named recipient one block later, and that block settles on Solana — its first was credited in block 2. Beta did the same for its two deposits, 13,000,000 lamports, before it stopped, and the alpha chain's portal took the first such deposit before either. Token deposits still only emit an event.

Solieum → Solana

In progress
  1. 01

    Initiate

    The withdrawal is recorded in Solieum state and the balance is debited there, so it cannot be spent twice. It is admitted only if the bridge can honour it: what Solana still owes to earlier withdrawals, plus this one, must fit inside what the vault can pay. A withdrawal can therefore be refused for a reason unrelated to your balance — the bridge is short — and the refusal costs a retry, not funds. Nothing is debited when it is refused. The gamma chain has run that rule since 2026-09-12, and the first refusal has been watched: a 500,000-lamport exit asked for against 100,000 of headroom, refused, with nothing debited and no leaf committed.

  2. 02

    Challenge window

    The state root containing the withdrawal sits in the 48-hour dispute period, during which anyone can prove it wrong and have it removed — for a step forged rather than merely mistaken, that holds once every step is bound to its signed transaction (ADR-0021), staged but not yet active. Nothing is released while it runs.

  3. 03

    Prove

    Once the root is final, the withdrawal is proven on Solana against it: a state-tree inclusion proof, with the commitment recomputed by the program from the id, amount, recipient and asset — so honest proof bytes cannot carry an inflated claim.

  4. 04

    Release

    After a short delay the vault pays the exact amount, once. Proving and paying are separate instructions on purpose, so a proof cannot be raced straight into a payout.

The challenge window is 48 hours (ADR-0016), and a 24-hour air gap follows it before payout — about three days in total, which is the number to read rather than either half. Seven days was the Ethereum optimistic-rollup convention and was never derived from Solana; the dispute game's own arithmetic needs hours. It is fixed when a chain is initialized and there is no setter: the beta devnet chain was initialized with it on 2026-09-05, and the alpha chain it replaced still enforces the seven days it was created with. The window has to be long enough that a challenge cannot be censored for its full duration — the parameter and the reasoning behind it are published together. A withdrawal has now been run end to end on the beta chain: initiated on the L2, the sender debited there, and the withdrawal leaf committed into a block whose root settled on Solana under bond. It is payable once that root is final, after the window and the air gap. The first such payout happened on 2026-09-07: a withdrawal on the beta chain, proven against its final root and paid by the vault on Solana's public devnet, the team's own fast-exit provider reclaiming its float. An ordinary withdrawal followed on 2026-09-10, walking the whole path a user walks: initiated on the L2, its balance debited there, proven against the final root, held for the portal's delay, then paid. Both were the team's own addresses, so the bar is unchanged: an exit by an unaffiliated user in a drill.

The rule the bridge cannot break

for every asset:   supply on Solieum  ≤  amount locked on Solana

No path may create a balance on Solieum without a matching, proven lock on Solana. This is enforced in the credit path itself rather than only monitored. The asset is part of every withdrawal commitment, so a proof for one mint cannot be spent against another's vault — the harness attacks that three ways and all three are refused with state untouched.

Custody today

In progress

There is no signer set. The bridge program holds deposits in a vault it owns, and the only path that releases funds is a withdrawal proven against a final state root — checked by the program with the same verifier the protocol's test gate runs, and out of reach of the pause flag by construction. One key can reach a proven withdrawal, and we would rather say so than let you find out: a guardian can deny a settlement ROOT during the delay between proof and payout, for the case a false root survives its challenge window through a bug or a censored challenger. That power is deliberately blunt — it names a root, never your withdrawal; it moves no money; and anyone, not only the guardian, can then reopen an affected claim and prove it again against a later root. It costs you time, not funds. What you trust more is the upgrade key: whoever holds it can change all of this code. Today it is a single operator key. The multisig, threshold and timelock that will hold it are published before mainnet, and the roadmap's last stage makes the timelock longer than the withdrawal window. The program is deployed and initialized on devnet at its pinned id, with a one-hour payout delay; mainnet is planned at twenty-four hours. The vault accepts deposits, and the node credits them on the L2 side; the first devnet deposit was credited end to end on 2026-09-02.

The full trust model →

Walkthrough

A deposit and a withdrawal, end to end

The flows above, replayed as one user's experience — including the waits and what they buy you.

  1. 01

    Deposit: you send SOL to the bridge program on Solana. It locks there — visibly, on-chain, auditable by anyone at any time.

  2. 02

    The deposit waits for Solana finality. This is well under a minute, and it exists so that a reorganisation on L1 cannot leave Solieum holding a credit backed by a deposit that un-happened.

  3. 03

    Your balance appears on Solieum, backed one-for-one by the locked SOL. You transact with soft confirmations from here.

  4. 04

    Withdrawal: you initiate on Solieum. Your L2 balance is burned immediately — the same value cannot be withdrawn twice or spent while in flight.

  5. 05

    The state root containing your withdrawal sits in the 48-hour challenge window. The wait is not processing time; it is the period in which anyone can prove that root wrong and have it removed — a guarantee that reaches a maliciously forged root, not only an honestly mistaken one, once every step is bound to its signed transaction (ADR-0021), which is specified and staged but not yet active.

  6. 06

    The window closes clean and the root is final. You prove the withdrawal on Solana against it — a proof that binds the amount, the recipient and the asset.

  7. 07

    Then a short delay, and the bridge pays your SOL out, exactly once. That delay is not queueing: it is the air gap, the one interval in which a guardian can deny a root the challenge window passed but the dispute machinery got wrong. It has never been used, and using it does not take your money — a denied root sends you back to prove the same withdrawal against the next honest one. Total elapsed: about three days — 48 hours of window, then the air gap. Nobody approves your withdrawal; at most, one key can send it round again.

Edge cases

What happens if…

The failure cases, answered directly rather than left to the imagination.

  • …Solana reorgs after my deposit?

    That is what the confirmation wait absorbs. Credits are issued only past the depth a reorg can plausibly reach, so a rolled-back deposit is never credited on L2.

  • …the sequencer halts mid-withdrawal?

    Your withdrawal was recorded on L2 and the burn stands. Once the state root containing it is final, the L1 proof-and-release path completes with no sequencer involvement.

  • …someone proves the root behind my withdrawal wrong?

    The root is removed during its window, before anything could be proven against it — withdrawals are provable only against final roots, so a removed root never pays anyone. Your withdrawal is still recorded in the honest state, and it is proven against the corrected root once that one is final. A delay, and exactly the system working.

  • …the bridge is paused while my withdrawal is pending?

    A pause stops new deposits. It cannot block a withdrawal that has already been proven, because the withdrawal path in the program does not read the pause flag at all — a design constraint, not a policy preference, and exercised in the harness: paused, deposit refused, proven withdrawal paid.

Controls

What limits the damage

  • Per-asset caps

    Limits on how much can move in a window, deferring rather than losing whatever exceeds them: a deposit over the cap moves nothing and is retried next window, a proven payout over the cap pays next window, a large withdrawal waits longer. Built in the on-chain program on 2026-09-12 (ADR-0013 D5), per asset and admin-set. Not deployed to any cluster, and a portal with no limits record is unlimited on every axis, so no chain is capped today.

  • Reconciliation

    Comparison of locked balances against issued supply, per asset, with an alarm on any drift. The invariant is enforced in the credit path today; the standing monitor is not yet built.

  • Pause

    New deposits can be halted by the admin. The withdrawal path cannot even read the pause flag, so a pause is structurally unable to block a proven withdrawal — exercised in the harness: paused, deposit refused, an already-proven withdrawal paid out.

  • Asset allowlist

    The vault speaks only the classic SPL Token program, pinned by id, with one vault account per mint. Extensions with transfer hooks, fees on transfer or permanent delegates cannot reach it, so one-to-one accounting is not assumed — it is the only thing the program can do.

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.