03Security
The trust model
What you are trusting when you use Solieum, stated in full — including the parts that are not finished.
What you are trusting, stated plainly
Bridge custody
In progressWithdrawals 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 progressInteractive 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 progressEvery 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 progressSubmit 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.
Settlement on Solana
In progressState roots are committed to the settlement program under bond and sit in a challenge window before they are final — 48 hours on the beta devnet chain (ADR-0016, initialized 2026-09-05), seven days on the frozen alpha chain that predates it. Live on devnet: the first block was published and committed within five seconds of its transaction, on both chains, checkable from Solana's public RPC without trusting the node.
Permissionless exit
PlannedWithdraw against the last final state root with no operator cooperation. The mechanism exists in the bridge program and a pause cannot block it by construction. On the beta devnet chain the first withdrawal was proven against a final root and paid by the vault after the air gap (2026-09-07), and all four of its withdrawals were paid before it stopped on 2026-09-12; the alpha chain's waits on its seven-day window. The exit is claimed only after a public drill by an unaffiliated user.
Sequencer
In progressOne sequencer, operated by Solieum, with forced inclusion as the guarantee: it can delay and order transactions, it cannot forge state once proofs enforce. Next stage: a staked, rotating sequencer set that decides ordering only. Finality stays with Solana.
External audit
PlannedIndependent audits of the settlement programs, bridge, and dispute game. Reports published in full, including accepted risks.
◆Evaluation
How to evaluate any Layer 2 — including this one
Six questions that cut through most L2 marketing. Ask them of Solieum, and ask them of everyone else. The honest answers are usually in a risk reviewer's table, not on a landing page.
- 01
Who can upgrade the contracts?
If a key or committee can change the bridge code, that party can take the funds — whatever the proofs say. Look for the timelock length, and whether it exceeds the withdrawal window. If upgrades can land faster than users can leave, the timelock is decorative.
- 02
Where is the transaction data?
On the settlement layer: a rollup, inheriting its availability. Somewhere else: a different trust model wearing the same name. Held by the operator: not a Layer 2 at all.
- 03
What makes an invalid state unfinalisable?
A working proof system in production, or nothing but the operator's honesty. Many launched L2s are the second, and say so only in the fine print. "Fraud proofs" that exist in a repo but do not gate finalisation protect nobody.
- 04
Can a user exit without permission?
The defining question. If the operator vanishing means funds are stuck, users are creditors, not customers. Ask whether the exit has ever been exercised by someone outside the team.
- 05
Who is watching, and who pays them?
Optimistic security assumes someone checks every root. If nobody is funded to verify, the honest security model is "trusted operator". Count the independent verifiers; ignore the validator marketing.
- 06
What can a pause block?
Circuit breakers are good; a pause that can block a proven withdrawal is custody with extra steps. Read what the emergency powers can touch and when they expire.
Applying those six to Solieum today
Upgrades: a single operator key; multisig and timelock to be published before mainnet — the table above says so. Data: on Solana, through the data-availability program, live on devnet. Proofs: the dispute game is deployed on devnet, decides disputes in the harness, and on the gamma chain, as on beta before it, its verdicts bind the settlement program; it enforces nowhere that holds real funds. Exit: built into the bridge program and exercised once on devnet by the team — a withdrawal proven against a final root and paid after the air gap; it will be exercised publicly by an unaffiliated user before it is claimed. Watchers: to be funded, counted, and named. Pauses: constrained by the rule that a proven withdrawal can never be blocked — the withdrawal path cannot even read the pause flag. System class: an optimistic rollup, and staying one; decentralisation goes into the sequencer set, never into a validator set deciding finality. That is a Stage 0 answer sheet, published on purpose.
◆Lessons
What the largest bridge losses teach, and what Solieum does about each
The biggest bridge losses of the last two years were not contract bugs. One bridge lost around $292M in April 2026 because a single verifier, reading the source chain through RPC nodes an attacker had replaced, attested to a lock that never happened. An exchange lost around $1.5B in February 2025 because a compromised signing front-end showed its signers one transaction and had them sign another. Neither was a flaw in the contract; both were a flaw in what the contract was told. Nothing below makes Solieum unhackable; each item says what it defeats and what it does not. The full decisions are ADR-0013, published in its own words under Decision records with the rest of the series.
- 01
There is no verifier to poison on the way out
Value leaves the vault only against a state-tree proof checked by the program against a root the settlement contract holds as final. No attester set, no configuration that can be quietly downgraded to one signer. The remaining work is authentication: for the fraud proof to reject a forged withdrawal, each step in that root must be bound to the signed transaction that authorised it — otherwise a proposer could place a step nobody signed into the root and win its dispute. That binding is specified in ADR-0021 and staged behind a version flag, not yet active; until it is, a forged withdrawal is held off by the chain's single trusted operator, not yet by the proof alone. What this does not cover: the way in.
- 02
The way in is the poisoned-verifier shape, and it is treated as one
A deposit reaches the L2 because the node reads the forced-inclusion inbox on Solana through an RPC. A poisoned RPC could make the node credit a deposit that never happened. Built: every fact the node reads from Solana is accepted only when all of its configured RPC providers agree byte for byte; a disagreement is refused and raised as an alarm rather than resolved by majority, and no deposit is credited unless the vault actually holds it. On a public cluster the node refuses to run with one provider unless the operator accepts that risk explicitly — which devnet does today, because no second keyless provider exists. And even then, a fake credit cannot be paid out until its root has cleared the challenge window, during which any verifier re-deriving from Solana sees a credit the inbox never backed and can dispute the root.
- 03
Monitoring never shares the path it monitors
In the $292M loss the tampered node answered the operator's monitoring honestly and the verifier dishonestly. On Solieum an independent watchtower re-derives the chain from Solana through its own RPC readers and alarms on divergence; it exists and is drilled, and nobody outside the operator runs one yet. It is one command, solieum-node verify --watch: its readers must agree before anything counts, a disagreement is reported as not-yet-derivable rather than as fraud, alarms go to a URL as well as the terminal, and on a real divergence it can open a challenge under bond. Drilled against a poisoned provider on 2026-09-04.
- 04
No single key, and signers who verify on-device
Mainnet upgrade authority is a multisig with a timelock longer than the challenge window plus the payout delay, so any upgrade can be seen and exited before it applies. Signers use hardware wallets with display-and-confirm; no signing front-end is trusted to describe what is being signed. Sequencer key, settlement payer and upgrade authority are three keys on three machines, none of them a developer's. Today's devnet runs on one hot key by design and says so.
- 05
A first-time anomaly hits a limit, not a human
Per-asset caps, withdrawal velocity limits and a longer delay for large withdrawals, all deferring rather than losing: a deposit over the cap moves nothing and is retried next window, a proven payout over the cap pays next window. The one-hour delay between proof and payout is live. The caps are built in the on-chain program as of 2026-09-12 and deployed to no cluster yet, so nothing is capped today, and the record says so itself.
- 06
People are in the threat model
Initial access in both incidents was a person: a developer's workstation, a fake job process. Two-person rule for production changes, no standing production access, human review of every dependency change, and production keys that never exist on a developer machine. These are process, not code, and they are listed as not built until they are.
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.