Search

Search for projects by name

Soon Alpha Mainnet logo
Soon Alpha Mainnet

Badges

About

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...


  • Total Value SecuredTVS
    $788.74 K3.12%
  • Past day UOPSDaily UOPS
    0.085.62%
  • Gas token
    ETH
  • Type
    Other

  • Purpose
    Universal

  • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    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...

    Why is the project listed in others?

    There is no data availability bridge

    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.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other

    2025 Jan 03 — Dec 11

    Past Day UOPS
    0.08
    Past Day Ops count
    7.19 K
    Max. UOPS
    6.82
    2025 May 28
    Past day UOPS/TPS Ratio
    1.00

    The section shows the operating costs that L2s pay to Ethereum.


    2025 Jan 03 — Dec 11


    Total cost
    $4.79 K
    Avg cost per L2 UOP
    $0.000571
    Avg cost per day
    $14.23

    This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereumEthereumEigenDAEigenDA.


    Data source: API provided by EigenLayer

    2025 Jan 02 — Dec 11


    Data posted
    4.30 GiB
    Avg size per day
    12.80 MiB
    Avg size per L2 UOP
    543.49 B

    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.

    No ongoing anomalies detected

    Avg. tx data subs. interval
    Avg. state updates interval
    Past 30 days anomalies
    This project includes unverified contracts.
    (CRITICAL)
    This project includes unverified contracts.
    (CRITICAL)
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Self sequence

    In the event of a sequencer failure, users can force transactions to be included in the project’s chain by sending them to L1. There can be up to a 12h delay on this operation.

    State validation
    Fraud proofs (1R, ZK)

    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.

    Data availability
    External

    Proof construction and state derivation fully rely on data that is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Sequencer transaction data roots are not checked against the DACert Verifier onchain.

    Exit window
    None

    There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.

    Proposer failure
    Self propose

    Anyone can be a Proposer and propose new roots to the L1 bridge.

    Data is posted to EigenDA

    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).

    1. EigenDA Docs - Overview
    2. Derivation: Batch submission - OP Mainnet specs
    3. BatchInbox - address
    4. OptimismPortal2.sol - source code, depositTransaction function
    Learn more about the DA layer here: EigenDA logoEigenDA
    State root proposals

    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.

    1. 'Sequencing' - Kailua Docs
    Challenges

    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:

    1. the proposal’s challenge period of 18h has ended before a conflicting proposal was made
    2. the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)
    3. a conflicting sibling proposal is proven faulty

    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).

    1. Disputes - Kailua Docs
    Validity proofs

    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.

    1. SOON Kailua - GitHub
    2. Risc0 Kailua Docs
    3. Verifier upgrade and deprecation - Kailua Docs

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x951f...8ecf
    None

    The system has a centralized operator

    The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.

    • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

    Users can force any transaction

    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.

    1. Sequencing Window - OP Mainnet Specs
    2. OptimismPortal2.sol - source code, depositTransaction function

    Regular exits

    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.

    1. OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function
    2. OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function

    Forced messaging

    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.

    1. Forced withdrawal from an OP Stack blockchain

    Solana Virtual Machine is supported

    OP stack chains are usually pursuing the EVM Equivalence model. But Soon implements the rust-based Solana virtual machine (SVM) which uses parallel processing.

    1. Soon Docs - Decoupled SVM
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Roles:

    Guardian EOA 1

    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).

    Sequencer EOA 2

    Allowed to commit transactions from the current layer to the host chain.

    Actors:

    SoonMultisig 0xD686…A701

    A Multisig with 2/4 threshold.

    • Can upgrade with no delay
      • SystemConfig
      • OptimismPortal2
      • L1ERC721Bridge
      • L1CrossDomainMessenger
      • DisputeGameFactory
      • SuperchainConfig
      • L1StandardBridge
    • Can interact with SystemConfig
      • it can update the preconfer address, the batch submitter (Sequencer) address and the gas configuration of the system
    • Can interact with AddressManager
      • set and change address mappings
    • Can interact with OptimismPortal2
      • freeze specific withdrawals
    • A Guardian - acting directly
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Contains configuration parameters such as the Sequencer address, gas limit on this chain and the unsafe block signer address.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
      • batcherHash: EOA 2
      • owner: SoonMultisig
    Can be upgraded by:

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
      • guardian: EOA 1
    • This contract stores the following tokens: ETH.
    Can be upgraded by:

    The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
    Can be upgraded by:

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
      • guardian: EOA 1
    Can be upgraded by:

    Used to bridge ERC-721 tokens from host chain to this chain.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
    Can be upgraded by:

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
    Can be upgraded by:

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately SoonMultisig
    • This contract can store any token.
    Can be upgraded by:
    RiscZeroVerifier 0x4552…6Bc6

    The source code of this contract is not verified on Etherscan.

    PermissionedDisputeGame 0x57d5…D087

    The source code of this contract is not verified on Etherscan.

    KailuaGame 0x62CF…Bd32

    Implementation of the KailuaGame with type 2000. Based on this implementation, new KailuaGames are created with every new state root proposal.

    ProxyAdmin 0x90b2…233d
    • Roles:
      • owner: SoonMultisig
    FaultDisputeGame 0xAa17…d36e

    The source code of this contract is not verified on Etherscan.

    KailuaTreasury 0xd6E6…3beb

    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.

    Value Secured is calculated based on these smart contracts and tokens:

    Main entry point for users depositing ERC20 token that do not require custom gateway.

    Can be upgraded by:

    Main entry point for users depositing ETH.

    Can be upgraded by:

    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).

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x951f...8ecf
    None