Search for projects by name
SOON is a Layer 2 chain built on top of the SOON Stack. It innovates with a Decoupled SVM that separates Solana's execution (needed for the SOON SVM) from its consensus (not needed since SOON settles on Ethereum), yielding performance and flexibility... improvements.
SOON is a Layer 2 chain built on top of the SOON Stack. It innovates with a Decoupled SVM that separates Solana's execution (needed for the SOON SVM) from its consensus (not needed since SOON settles on Ethereum), yielding performance and flexibility... improvements.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
2025 Jan 03 — Dec 11
The section shows the operating costs that L2s pay to Ethereum.
2025 Jan 03 — Dec 11
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to
Ethereum
EigenDA.
2025 Jan 02 — Dec 11
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
Fraud proofs allow actors watching the chain to prove that the state is incorrect. Single round proofs (1R) prove the validity of a state proposal, only requiring a single transaction to resolve. A fault proof eliminates a state proposal by proving that any intermediate state transition in the proposal results in a different state root. For either, a ZK proof is used.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Since the DACert Verifier is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments. If EigenDA becomes unavailable, the sequencer falls back to Ethereum.
Funds can be lost if the sequencer posts an unavailable transaction root (CRITICAL).
Funds can be lost if the data is not available on the external provider (CRITICAL).
Proposers submit state roots as children of any (possibly unresolved) previous state root proposal, by calling the propose() function in the KailuaTreasury. A parent state root can have multiple conflicting children, composing a tournament. Each proposer requires to lock a bond, currently set to 0.01 ETH, that can be slashed if any proposal made by them is proven incorrect via a fault proof or a conflicting validity proof. The bond can be withdrawn once the proposer has no more pending proposals that need to be resolved and was not eliminated.
Proposals consist of a state root and a reference to their parent and implicitly challenge any sibling proposals who have the same parent. A proposal asserts that the proposed state root constitutes a valid state transition from the parent’s state root. To offer efficient zk fault proofs, each proposal must include 100 intermediate state commitments, each spanning 50 L2 blocks.
Proposals target sequential tournament epochs of currently 100 * 50 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 18h.
Any conflicting sibling proposals within a tournament that are made within the 18h challenge period of a proposal they are challenging, delay resolving the tournament until sufficient ZK proofs are published to leave one single tournament survivor.
In the tree of proposed state roots, each parent node can have multiple children. These children are indirectly challenging each other in a tournament, which can only be resolved if but a single child survives. A state root can be resolved if it is the only remaining proposal due to any combination of the following elimination methods:
Proving any of the 100 intermediate state commitments in a proposal faulty invalidates the entire proposal. Proving a proposal valid invalidates all conflicting siblings. Pruning of a tournament’s children happens strictly chronologically, which guarantees that the first faulty proposal of a given proposer is always pruned first. When pruned, an invalid proposal leads to the elimination of its proposer, which invalidates all their subsequent proposals, slashes their bond, and disallows future proposals by the same address. A slashed bond is transferred to an address chosen by the prover who caused the slashing.
A single remaining child in a tournament can be ‘resolved’ and will be finalized and usable for withdrawals after an execution delay of 8h (time for the Guardian to manually blacklist malicious state roots).
Validity proofs and fault proofs both must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
The Kailua state validation system is primarily optimistically resolved, so no validity proofs are required in the happy case. But two different zk proofs on unresolved state roots are possible and permissionless: The proveValidity() function proves a state root proposal’s full validity, automatically invalidating all conflicting sibling proposals. proveOutputFault() allows any actor to eliminate a state root proposal for which they can prove that any of the 100 intermediate state transitions in the proposal are not correct. Both are zk proofs of validity, although one is used as an efficient fault proof to invalidate a single conflicting state transition.
Funds can be stolen if the validity proof cryptography is broken or implemented incorrectly.
Funds can be stolen if no challenger checks the published state
Funds can be stolen if the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector.
Funds can be frozen if a verifier needed for a given proof is paused by its permissioned owner.
Name | Hash | Repository | Verification | Used in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x951f...8ecf | None | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.
The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 8h. Withdrawal inclusion can be proven before state root settlement, but a 8h period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 18h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.
OP stack chains are usually pursuing the EVM Equivalence model. But Soon implements the rust-based Solana virtual machine (SVM) which uses parallel processing.

Allowed to pause withdrawals. In op stack systems with a proof system, the Guardian can also blacklist dispute games and set the respected game type (permissioned / permissionless).
Allowed to commit transactions from the current layer to the host chain.
A Multisig with 2/4 threshold.

The main entry point to deposit funds from host chain to this chain. It also allows to prove and finalize withdrawals. This version (originally from SOON) of the OptimismPortal is modified to support Solana addresses. It disallows ERC20 token deposits and L1->L2 transactions that would create a contract. Withdrawals can be frozen / blacklisted by a permissioned actor. Has a MIN_BRIDGE_VALUE set to 0.001 ETH.
The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.
This is NOT the shared SuperchainConfig contract of the OP stack Superchain but rather a local fork. It manages the PAUSED_SLOT, a boolean value indicating whether the local chain is paused, and GUARDIAN_SLOT, the address of the guardian which can pause and unpause the system.
Used to bridge ERC-721 tokens from host chain to this chain.
Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limit, it can be resubmitted via this contract’s replay function.
The main entry point to deposit ETH from host chain to this chain. This version (originally from SOON) is modified to support Solana addresses. It requires specifying the destination SOL address and removes support for ERC20 tokens.
The source code of this contract is not verified on Etherscan.
The source code of this contract is not verified on Etherscan.
Implementation of the KailuaGame with type 2000. Based on this implementation, new KailuaGames are created with every new state root proposal.
The source code of this contract is not verified on Etherscan.
Entrypoint for state root proposals. Manages bonds (currently 0.01 ETH) and tournaments for the OP Kailua state validation system, wrapping the OP stack native DisputeGameFactory.
Main entry point for users depositing ERC20 token that do not require custom gateway.
Main entry point for users depositing ETH.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).
Name | Hash | Repository | Verification | Used in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x951f...8ecf | None | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||