Search

Search for projects by name

MegaETH logo
MegaETH

Badges

About

MegaETH is a real-time blockchain based on the OP Stack architecture and the hybrid Kailua proof system, targeting sub-millisecond latency and over 100,000 transactions per second.


  • Total Value SecuredTVS
    $0.000.00%
  • Past day UOPSDaily UOPS
    No data
  • Gas token
    ETH
  • Type
    Other

  • Purpose
    Universal
  • Chain ID
    4326

  • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    MegaETH is a real-time blockchain based on the OP Stack architecture and the hybrid Kailua proof system, targeting sub-millisecond latency and over 100,000 transactions per second.

    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
    This project includes unverified contracts.
    (CRITICAL)
    Under Review

    The information in the section might be incomplete or outdated.
    The L2BEAT Team is working to research & validate the content before publishing.

    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
    Under Review

    This risk is currently under review.

    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
    Cannot withdraw

    Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

    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
    A diagram of the state validation
    A diagram of the state validation
    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.00001 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 3600 intermediate state commitments, each spanning 1 L2 blocks.

    Proposals target sequential tournament epochs of currently 3600 * 1 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 7d.

    The Vanguard is a privileged actor who can always make the first child proposal on a parent state root. They can, in the worst case, delay each tournament for up to 36558901084y 8mo by not making this first proposal. Sibling proposals made after the Vanguard’s initial one or after the 36558901084y 8mo vanguardAdvantage in each tournament are permissionless.

    1. 'Sequencing' - Kailua Docs
    2. Vanguard - Kailua Docs
    Challenges

    Any conflicting sibling proposals within a tournament that are made within the 7d 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 7d 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 3600 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 3d 12h (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 3600 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. Risc0 Kailua Docs
    2. Verifier upgrade and deprecation - Kailua Docs

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0xf0ce...22c2
    Code unknown
    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 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 7d 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

    EVM compatible smart contracts are supported

    OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.

    1. Introducing EVM Equivalence
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Roles:

    Guardian EOA 2

    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 1

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

    Actors:

    A Multisig with 4/7 threshold.

    • Can upgrade with no delay
      • L1StandardBridge
      • SystemConfig
      • L1ERC721Bridge
      • SuperchainConfig
      • L1CrossDomainMessenger
      • OptimismPortal2
      • DisputeGameFactory
      • DelayedWETH
      • AnchorStateRegistry
      • OptimismMintableERC20Factory
    • 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 DelayedWETH
      • can pull funds from the contract in case of emergency
    • Can interact with AddressManager
      • set and change address mappings

    A Multisig with 4/6 threshold.

    • Can interact with MegaPreDepositVaultRefund
      • manage all access control roles
      • service (execute) refunds from this contract

    A Multisig with 1/1 threshold.

    Participants (1):

    EOA 2
    Megaeth Multisig 0xCB26…b719

    A Multisig with 4/6 threshold.

    Member of Safe, Safe, Megaeth Multisig, Safe.

    • Can interact with RiscZeroVerifierRouter
      • add/remove verifiers and the selectors they are mapped to
    • A Guardian Safe
    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 Safe
      • batcherHash: EOA 1
      • owner: Safe
    Can be upgraded by:

    The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the KailuaGame.

    • Roles:
      • admin: ProxyAdmin; ultimately Safe
    • 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 Safe
    Can be upgraded by:
    Implementation used in:

    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 Safe
      • guardian: Safe; ultimately EOA 2
    Can be upgraded by:

    The main entry point to deposit ERC20 tokens from host chain to this chain.

    • Roles:
      • admin: ProxyAdmin; ultimately Safe
    • This contract can store any token.
    Can be upgraded by:
    Implementation used in:

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

    • Roles:
      • admin: ProxyAdmin; ultimately Safe
    Can be upgraded by:
    Implementation used in:

    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 Safe
    Can be upgraded by:
    Implementation used in:
    ProxyAdmin 0x15fC…8d90
    • Roles:
      • owner: Safe
    PreimageOracle 0x1fb8…aDD3

    The PreimageOracle contract is used to load the required data from L1 for a dispute game.

    Implementation used in:
    MegaPreDepositVaultRefund 0x22cf…3071

    Refund escrow designed to hold the funds extracted from the predeposit vault and send them back to the users listed in the vault.

    • Roles:
      • defaultAdmin: Safe
      • executor: Safe
    RiscZeroSetVerifier 0x411e…85C3

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

    MegaUSDmPreDeposit 0x46D6…45D6

    Predeposit Escrow, not connected to an L2: Users can deposit USDC. The system uses off-chain permit signatures to ensure only KYC’d users can deposit. Withdrawals can only be made by Megaeth Multisig to MegaPreDepositVaultRefund.

    • Roles:
      • owner: Megaeth Multisig
      • permitSigner: EOA 3
    • This contract stores the following tokens: USDC.
    KailuaGame 0x78F8…71C9

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

    Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.

    • Roles:
      • admin: ProxyAdmin; ultimately Safe
      • owner: Safe
    Can be upgraded by:
    Implementation used in:
    RiscZeroVerifierRouter 0x910b…C057

    A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (0x0A383fF8387CF07315f476D1686E95b1a97adc97).

    • Roles:
      • owner: EOA 2
    ProxyAdmin 0xab48…d07A
    • Roles:
      • owner: Safe
    PermissionedDisputeGame 0xB2E4…2152

    Same as FaultDisputeGame, but only two permissioned addresses are designated as proposer and challenger.

    KailuaTreasury 0xE4e4…D623

    Entrypoint for state root proposals. Manages bonds (currently 0.00001 ETH) and tournaments for the OP Kailua state validation system, wrapping the OP stack native DisputeGameFactory.

    Contains the latest confirmed state root that can be used as a starting point in a dispute game.

    • Roles:
      • admin: ProxyAdmin; ultimately Safe
    Can be upgraded by:
    Implementation used in:

    The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.

    Implementation used in:

    A helper contract that generates OptimismMintableERC20 contracts on the network it’s deployed to. OptimismMintableERC20 is a standard extension of the base ERC20 token contract designed to allow the L1StandardBridge contracts to mint and burn tokens. This makes it possible to use an OptimismMintableERC20 as this chain’s representation of a token on the host chain, or vice-versa.

    • Roles:
      • admin: ProxyAdmin; ultimately Safe
    Can be upgraded by:
    Implementation used in:

    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:
    Implementation used in:

    Main entry point for users depositing ETH.

    Can be upgraded by:
    Escrow for USDC 0x46D6…45D6

    Predeposit escrow for USDC that can only be deposited to after passing KYC and only be withdrawn to a single address.

    Multisig currently designated as the ‘Treasury’.

    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
    0xf0ce...22c2
    Code unknown
    None