Security and Trust Assumptions

What the operator can do to you, what it cannot, the two timers between a state root and your money, the eight decisions taken after the 2026 bridge losses, and what none of it defeats.

Nothing here claims the system cannot be hacked. It says which attacks each control defeats, which it merely makes expensive, and which it does not address at all.

What the sequencer can and cannot do

The right-hand column is only as good as the machinery behind it. Every item's real status is in Status and Roadmap, and the mechanism behind each is in Technical Architecture.

The two timers

A withdrawal crosses two waits, and they answer different questions. Conflating them is how a single seven-day number ends up doing two jobs badly.

The challenge window answers: was this root challenged?

Its length is arithmetic, not convention. A dispute is 2 × ceil(log2(steps)) + 1 moves, and for the largest trace the proposer bond can fund, 131,072 steps, that is 35 moves.

48 hours, stored as 432,000 slots, clears both with margin. The round length is the parameter with the least slack in it and should not be lengthened without re-running this arithmetic.

Seven days, the number this project used before, is the Ethereum optimistic-rollup convention. It was never derived from anything on Solana, and no chain settling to Solana ships it. A seven-day exit is now a number a builder reads as a mistake rather than as caution.

The air gap answers: was the dispute machinery itself sound?

No length of window answers that one. A bug in the one-step verifier or the state-tree check means a false root wins its game, or is never challenged because the tooling that would have challenged it was wrong. A challenger who is right and censored for the whole window has the same effect. What that needs is not more time but an interval with a hand on it.

So the payout delay is an air gap, 24 hours by the mainnet design, in which a guardian may deny a settlement root. Denial names a root and never a withdrawal, moves no money, and is remedied permissionlessly by anyone reproving against a later root. It costs you time, not funds. The mechanics are on the Wallet Bridge page, including the fact that this is the one key that can reach a withdrawal you have already proven.

Quote the total. 48 hours plus 24 hours is about three days. The window alone is not the exit.

What the bridge trusts, in each direction

Withdrawals are the strong direction

There is no verifier set and no attester. Value leaves the vault only against a state-tree inclusion proof of a withdrawal leaf, checked by the program against a root the settlement program holds as final. There is no configuration that can be downgraded to a single signer, because there is no signer on that path at all. A forged withdrawal needs a forged final root, which is what the proof system is designed to prevent.

That design is not yet fully enforced, and it must be said as plainly as the deposit direction below. The fraud proof re-checks a disputed step against the root the proposer submitted, but a settled root's steps are not yet bound to the signed transactions that produced them, so today a forging proposer — not an outside attacker — could commit a step no user signed and win the dispute over it. What prevents that now is not the proof but the posture around it: a single operator holds the only sequencer key, the challenge window and payout delay run their course, the vault pays only what it holds, and the live chains carry no value. Binding each step to a signed transaction in the published batch is a specified change that must land before the sequencer set opens to anyone untrusted or the bridge holds value; until it does, finality on a user-signed step rests on trusting the operator, and this paper will not claim otherwise.

Deposits are the weak direction, and it must be said plainly

A deposit is an entry on a Solana queue, and the node learns of it by reading Solana through an RPC.

That is the shape of the largest bridge loss of 2026, in which no smart contract was exploited and every contract behaved as designed. A single verifier learned about the source chain through RPC nodes. Two of those were compromised to return tampered responses to the verifier while answering the operator's monitoring honestly, and the honest endpoints were flooded so failover routed to the poisoned ones. The verifier attested to a lock that had never happened, and supply entered circulation without backing: an accounting invariant broken by infrastructure, not by code. A second and third attempt carrying the same message were caught by humans, because nothing automatic limited a first-time anomaly.

The February 2025 exchange loss belongs to the same family from the other side: no contract bug, a compromised signing front end showed the signers one transaction and had them sign another.

The eight decisions that follow, and what each one does not defeat

These are binding on the mainnet design. What is built today and what is not is tracked in Status and Roadmap.

D1. The minting path trusts no single RPC. Every Layer 1 fact the node acts on for value, inbox entries and deposit records, the settlement head, the vault balance, is read from at least two independent providers run by different operators on different infrastructure. A deposit is credited only when they agree on the entry's bytes and its inclusion state. Disagreement is not resolved by majority: it halts deposit crediting and raises an alarm. A single-endpoint configuration is refused at startup on any cluster except a local validator. Defeats one poisoned or DDoS-failed-over provider. Does not defeat every configured provider compromised together, or a compromise of Solana itself.

D2. Every exit and every credit is checked against what the vault can pay. What the vault can pay is its balance less the rent floor it must keep, computed by the same function, on the cluster's own rent parameters, that the portal uses when it pays out. On a chain with a portal, the node refuses a withdrawal when what Layer 1 still owes, committed exits not yet paid plus this one, would exceed that. It refuses a credit that would push everything minted through the bridge above everything ever deposited, which is what the vault can pay plus what it has already paid out. Until it has read the vault, it refuses exits rather than guessing. An independent verifier asserts both rules at the head through its own Layer 1 readers, never the operator's, and a breach is a divergence-class alarm, not a log line. Defeats the outcome of that 2026 loss: neither a mint without backing nor a balance that never came through the bridge, such as a test chain's genesis allocation, can become withdrawals beyond what the vault can pay. Does not defeat a fake credit that stays within what was ever deposited, which is what D1 and the derivation fault are for. Nor does it stop a withdrawal of unbridged balance while the vault can still cover it: the rule bounds how much leaves, not whose it was, and keeping such balance out of the withdrawable set is a recorded alternative that was not taken. Users bear a cost for it: an exit can be refused because the vault is short, not because their balance is.

D3. Monitoring never shares infrastructure with the path it monitors. Independent verifiers use providers disjoint from the sequencer's. The sequencer's own alarms are not the security signal; a verifier's divergence alarm is. Defeats exactly the failure in that incident, where the tampered node answered monitoring honestly.

D4. No single key over user funds, and the timelock outlasts the exit. Mainnet upgrade authority is a multisig behind a timelock longer than the whole exit, window plus air gap, so any upgrade can be seen and exited before it takes effect. Signers use hardware wallets that display and confirm; a signing front end is never trusted to describe what is being signed. The sequencer's receipt key, the settlement payer and the upgrade authority are three different keys on three different machines, and production keys never exist on a developer machine. Defeats one compromised signer or laptop, and a lying signing interface. Does not defeat a quorum acting together, which is why the quorum is published.

D5. Limits a first-time anomaly cannot exceed. Per-asset deposit caps, a withdrawal velocity limit per window, and a large-withdrawal tier that lengthens the payout delay. Caps defer, they do not lose. Defeats a single-shot drain. Does not defeat slow extraction under the cap, which is what D1 to D3 are for.

D6. The pause can stop new value in, never proven value out. The withdrawal path cannot read the pause flag; that is structural, not policy. An emergency guardian, 2-of-3 and separate from the upgrade authority, may pause deposits and new roots, and its pause expires on its own. Defeats a bad batch or a discovered exploit continuing. Does not defeat an exploit already proven against a final root. By construction nothing can, and that is the property users are paying for.

D7. Reproducible builds and a clean-clone gate. Every deployed program's bytes must be reproducible from source with the verification command published, and the gate runs on a clean checkout. Defeats an unnoticed difference between audited source and deployed bytes. Does not defeat a malicious change that is committed and audited as such.

D8. People are in the threat model. A two-person rule for production changes, no standing production access, dependency additions reviewed by a human with the usual auditing tools in continuous integration, and a written playbook for the recruiter and fake-interview approaches used in the large losses of recent years. Defeats the most common initial access of the last three years. Does not defeat a determined insider, which is what D4's quorum and D3's independence are for.

The keys

The upgrade key is the one you actually trust. Today it is one key, which is stated rather than obscured, and the multisig, threshold and timelock that will replace it are published before mainnet rather than after.

Permissionless exit

If Solieum stops entirely, the sequencer gone and the operator unreachable, you prove what you own against the last final root and withdraw on Solana. No cooperation, no permission, and the payout instruction can be sent by anyone.

The on-chain side exists and is demonstrated end to end, including the refusal of an inflated claim riding a genuine proof. What is missing is public tooling to build your own proof without the operator's node, and a drill in which an unaffiliated person walks the path. Until then it is mechanism built, not exit proven.

Who is actually watching

Fraud proofs protect nobody unless somebody runs a verifier and checks. If fraud never happens, nobody is paid for watching, and the rational choice is to stop, which is exactly when attempting fraud becomes worthwhile.

Solieum treats independent verification as infrastructure to fund rather than goodwill to hope for: a one-command verifier, drilled against a deliberately poisoned provider, and a reward path for verifiers and challengers among the token's first jobs. The gap that remains is the one that matters: nobody outside the operator runs one yet.

Audits

There have been none. Two sequential audits plus a proof-system specialist are planned before mainnet, with findings published, alongside a bug bounty sized to value at risk.

What this does not claim

• It does not make Solieum unhackable. It moves the single points of failure that recent incidents exploited into a quorum, a proof, or a delay long enough to see.
• It does not replace audits or a bounty.
• It does not address Solana-level failures. A deep reorg or a base-layer runtime bug is inherited, and there is no control here for it.
• None of it is currently protecting anyone's money. There is no mainnet and no user funds. Today's honest posture is machinery deployed on a test network, largely unexercised by adversaries, and unaudited.