{
"architectureImage": "opstack-rollup-superchain-opfp-kailua",
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
"risks": [],
"references": [
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0x3A75346f81302aAc0333FB5DCDD407e12A6CfA83#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exits",
"description": "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 1d. Withdrawal inclusion can be proven before state root settlement, but a 1d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": [
{
"title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
}
]
},
{
"name": "Forced messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "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.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xB250566074B3c0f1B109A531A83f3d9B1a579273#code"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "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.",
"risks": [],
"references": [
{
"title": "Introducing EVM Equivalence",
"url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "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.5 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.\n\nProposals 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 6 L2 blocks. \n\nProposals target sequential tournament epochs of currently 3600 * 6 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 3d. \n\nThe **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 1mo by not making this first proposal. Sibling proposals made after the Vanguard's initial one or after the 1mo vanguardAdvantage in each tournament are permissionless.",
"references": [
{
"title": "'Sequencing' - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/design.html#sequencing"
},
{
"title": "Vanguard - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/parameters.html#vanguard-advantage"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "the vanguard exploits their vanguard advantage (1mo), halting the chain until they propose."
}
]
},
{
"title": "Challenges",
"description": "\nAny conflicting sibling proposals within a tournament that are made within the 3d challenge period of a proposal they are challenging, delay resolving the tournament until sufficient ZK proofs are published to leave one single tournament survivor.\n\nIn 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: \n1. the proposal's challenge period of 3d has ended before a conflicting proposal was made\n2. the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)\n3. a conflicting sibling proposal is proven faulty\n\nProving 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.\n\nA single remaining child in a tournament can be 'resolved' and will be finalized and usable for withdrawals after an execution delay of 1d (time for the Guardian to manually blacklist malicious state roots).",
"references": [
{
"url": "https://boundless-xyz.github.io/kailua/dispute.html",
"title": "Disputes - Kailua Book"
}
]
},
{
"title": "Validity proofs",
"description": "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.\n\nThe 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.",
"references": [
{
"url": "https://risczero.com/blog/kailua-how-it-works",
"title": "Risc0 Kailua Docs"
},
{
"url": "https://github.com/risc0/risc0-ethereum/blob/main/contracts/version-management-design.md",
"title": "Verifier upgrade and deprecation - Kailua Docs"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "no challenger checks the published state."
},
{
"category": "Funds can be stolen if",
"text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector."
},
{
"category": "Funds can be frozen if",
"text": "a verifier needed for a given proof is paused by its permissioned owner."
}
]
}
]
},
"stateValidationImage": "kailua"
}
eigenda+5-0
daLayer+5-0
{
"finality": 600,
"pruningWindow": 1209600,
"risks": {
"economicSecurity": {
"value": {
"value": "No slashing",
"sentiment": "bad",
"description": "Node operators are required to stake a minimum of 32 ETH (first quorum) or 1 EIGEN (second quorum) to become members of the DA network. Although slashing is enabled at EigenLayer protocol level, individual AVSs like EigenDA need to activate it by migrating to Operators Sets and defining slashing conditions. Currently, there is no slashing condition in place for misbehaving nodes. The EIGEN token social forking protocol for intersubjective attributable faults is under active development."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"sovereignProjectsTrackingConfig": [
{
"projectId": "mantle-testnet",
"name": "Mantle-testnet",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0xc16267ecb2297f8a98fce214686e80697da91198"
}
]
},
{
"projectId": "matter-labs-wonderfi",
"name": "Matter Labs - WonderFi",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0xdaf4b26d608d58f53ab6f0758a12de01296ce5bf"
}
]
},
{
"projectId": "altlayer",
"name": "AltLayer",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0x4fdbd273b8d2c1c429a7e3078063c49528aa8264"
}
]
},
{
"projectId": "altlayer-2",
"name": "AltLayer-2",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0x1359fbd4b9bc9441a90436719426157526742c9a"
}
]
},
{
"projectId": "altlayer-cyber",
"name": "Altlayer Cyber",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "35.167.254.127"
}
]
},
{
"projectId": "conduit",
"name": "Conduit",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0x8dc6f0bd2ce3c40d633f5541e21e7574598f7c75"
}
]
},
{
"projectId": "layer-n",
"name": "Layer N",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0xd697219f32129f4544a554be015386fac9445507"
}
]
},
{
"projectId": "treasure",
"name": "Treasure",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 0,
"customerId": "0x96561d11f55f99f7cda780b77e524195bde1dcde"
}
]
},
{
"projectId": "openledger",
"name": "OpenLedger",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1752044400,
"customerId": "0xe16fabeb99a6c098e4d7b4d442df0c827d5a6d26"
}
]
},
{
"projectId": "alchemy-production",
"name": "Alchemy Production",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1753833600,
"customerId": "0x3ba8c28a0209dea4d0502031f83d09a17a389fb0"
}
]
},
{
"projectId": "powerloom",
"name": "Powerloom",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1754438400,
"customerId": "0x00efb491755397ab8727ab45c4aef5fdcd3ecef8"
}
]
},
{
"projectId": "soon-base",
"name": "SOON - Base",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1748934000,
"customerId": "0xa11b7dea1592011c0055c62efb9566a845493003"
}
]
},
{
"projectId": "polymer",
"name": "Polymer",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1731974400,
"customerId": "0xf33f8cfea5857ebf248520cf6bc33640680ff83b"
}
]
},
{
"projectId": "crestal",
"name": "Crestal",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1728399600,
"customerId": "0x2659d4555e482ec4131a493def0770a922c75de3"
}
]
},
{
"projectId": "megaeth",
"name": "MegaETH",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1722405600,
"customerId": "0xcd1161b78f01da838ce0d42ec750891ec8708f1d"
}
]
},
{
"projectId": "conduit-2",
"name": "Conduit",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1719266400,
"customerId": "34.145.120.220"
}
]
},
{
"projectId": "conduit-3",
"name": "Conduit",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1719262800,
"customerId": "34.168.104.248"
}
]
}
],
"systemCategory": "public",
"technology": {
"description": "\n\n ## Architecture\n\n \n\n EigenDA is composed by three types of off-chain entities: node operators, a disperser and a retriever.\n - EigenDA **operators** are node operators running the EigenDA node software and are registered to the EigenDA AVS in EigenLayer.\n - The **disperser** is the entity responsible for collecting the blobs from the sequencer, erasure coding them and generating the encoded blob's KZG commitments for each chunk. Although the disperser could be rollup-operated, it is currently a centralised entity operated by Eigen Labs.\n - Lastly, the **retriever** client is responsible for querying the EigenDA operators to retrieve blob chunks, verifying their integrity and reconstructing the original blob. \n \n ### Operators Registration \n Operators register with the EigenDAServiceManager via the registerOperatorToAVS() function, enabling them to participate in the data availability network. They are responsible for holding and serving blobs data, and earn rewards for their participation in the network.\n\n \n\n ### Operators Stake Update \n \n EigenDA operators' stake for quorum verification is fetched from the EigenDA StakeRegistry contract. To keep the stake in sync with changes in share balances in the EigenLayer DelegationManager (e.g., due to tokens delegated/undelegated to operators), the permissionless updateOperators() function on the RegistryCoordinator contract needs to be called periodically. This function updates the operators' quorum weight in the StakeRegistry contract based on the operators' shares in the EigenLayer DelegationManager contract.\n \n\n ### Operators Blob Storage and Retrieval \n\n The process of storing a blob on EigenDA works as follows. A sequencer submits blobs to the EigenDA Disperser, which erasure codes the blobs into chunks and generates KZG commitments and proofs for each chunk, certifying the correctness of the data. The disperser then sends the chunks, KZG commitments, and KZG proofs to the operators.\n Multiple operators are responsible for storing chunks of the encoded data blobs and their associated KZG commitment and proof.\n Once the chunks, KZG commitments, and KZG proofs are sent to the operators, each of them generates a signature certifying that they have stored the data. These signatures are then sent to the Disperser which aggregates them and submits them to Ethereum by sending a transaction to the EigenDAServiceManager (the DA bridge).\n \n \n\n ## Data Availability Certificates\n\n EigenDA uses different certificate formats depending on the version, each with corresponding verifier contracts:\n\n ### Certificate Types\n - **V1 Certificates**: Used in EigenDA V1, verified through the EigenDAServiceManager contract via the confirmBatch() function. These certificates contain batch headers with KZG commitments and BLS aggregated signatures from operators.\n \n - **V2/V3 Certificates**: Used in EigenDA V2, which introduces significant architectural changes. The sequencer acts as the relayer and does not post batches to the service manager. Instead, certificates are verified through dedicated DACert Verifier contracts that correspond to different certificate versions.\n\n ### EigenDA V2 Changes\n In EigenDA V2, the architecture has evolved to improve efficiency:\n - **Sequencer as Relayer**: The sequencer now acts as the relayer, eliminating the need to post batches to the service manager\n - **Direct Certificate Verification**: Certificates are verified directly through version-specific DACert Verifier contracts\n - **Improved Throughput**: The new architecture supports higher throughput by removing bottlenecks in the batch confirmation process\n\n ### Certificate Verification Process\n 1. **Certificate Construction**: The EigenDA client constructs certificates from BlobStatusReply data received from the disperser\n 2. **Version Detection**: The certificate version is determined from the commitment structure\n 3. **Verifier Selection**: The appropriate DACert Verifier contract is selected based on the certificate version\n 4. **Onchain Verification**: The verifier contract's checkDACert function validates the certificate against operator signatures and stake thresholds\n\n ## L2 Data Availability\n The verification process differs between EigenDA versions:\n\n **EigenDA V1**: The Disperser collects operators' signatures and submits them to the EigenDAServiceManager contract via the confirmBatch() function. This submission includes a call to the BLSRegistry contract to verify signatures and check whether the required quorum of operators' stake has been achieved.\n\n **EigenDA V2**: Certificate verification is handled by dedicated DACert Verifier contracts. Each certificate version corresponds to a specific verifier that validates the certificate format and cryptographic proofs without requiring batch submissions to a central service manager.\n\n Threshold BLS signatures are not used. Instead, the threshold check is performed on the signers' total stake fetched by the StakeRegistry, and the stake threshold percentage to reach is provided in the batch header input data.\n\n The EigenDARollupUtils.sol library's verifyBlob() function can then be used by L2s to verify that a data blob is included within a confirmed batch in the EigenDAServiceManager (V1) or through the appropriate DACert Verifier contract (V2/V3). \n This function is not used by the EigenDAServiceManager contract itself, but rather by L2 systems to prove inclusion of the blob and that their trust assumptions (i.e., batch confirmation threshold) were as expected.\n ",
"references": [
{
"title": "EigenDA - Documentation",
"url": "https://docs.eigenda.xyz/overview"
},
{
"title": "EigenDA Integration Spec - Lifecycle Phases",
"url": "https://layr-labs.github.io/eigenda/integration/spec/5-lifecycle-phases.html#secure-dispersal"
},
{
"title": "EigenDA Disperser - Source Code",
"url": "https://github.com/Layr-Labs/eigenda/blob/2ed86a0c1dd730b56c8235031c19e08a9837bde8/disperser/batcher/batcher.go"
},
{
"title": "EigenDA Rollup Utils - Source Code",
"url": "https://github.com/Layr-Labs/eigenda-utils/blob/c4cbc9ec078aeca3e4a04bd278e2fb136bf3e6de/src/libraries/EigenDARollupUtils.sol"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "the disperser does not distribute data to EigenDA operators."
}
]
},
"throughput": [
{
"size": 15728640,
"frequency": 1,
"sinceTimestamp": 1719187200
},
{
"size": "NO_CAP",
"frequency": 1,
"sinceTimestamp": 1753833600
}
],
"type": "DA Service",
"usedWithoutBridgeIn": [
{
"id": "aevo",
"name": "Aevo",
"slug": "aevo"
},
{
"id": "fuel",
"name": "Fuel Ignition",
"slug": "fuel"
},
{
"id": "mantle",
"name": "Mantle",
"slug": "mantle"
},
{
"id": "megaeth",
"name": "MegaETH",
"slug": "megaeth"
},
{
"id": "soon",
"name": "Soon Alpha Mainnet",
"slug": "soon"
}
],
"validators": {
"type": "static",
"count": 113
}
}
{
"badges": [],
"description": "MegaETH is developing a real-time blockchain based on the OP stack architecture and the hybrid Kailua proof system, where crypto applications leverage extreme performance to reach their full potential. The project is in a pre-deposit phase during which the implementation of the Layer 2 system is yet unknown.",
"badges": [
{
"id": "EVM",
"type": "VM",
"name": "EVM",
"description": "This project uses the Ethereum Virtual Machine to run its smart contracts and supports the Solidity programming language",
"action": {
"type": "scalingFilter",
"id": "vm",
"value": "EVM"
}
},
{
"id": "EigenDA",
"type": "DA",
"name": "EigenDA",
"description": "This project is posting its data to EigenDA",
"action": {
"type": "publicDaHighlight",
"slug": "eigenda"
}
},
{
"id": "OPKailua",
"type": "Stack",
"name": "Built on the OP Kailua stack",
"description": "The project is built on the OP Kailua stack"
}
],
"description": "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.",
"links": {
"websites": [
"https://megaeth.com/"
],
"bridges": [
"https://predeposit.megaeth.com/"
],
"documentation": [
"https://docs.megaeth.com/"
],
"explorers": [
"https://megaexplorer.xyz/"
],
"repositories": [
"https://github.com/megaeth-labs"
],
"socialMedia": [
"https://x.com/megaeth",
"https://discord.com/invite/megaeth",
"https://t.me/megaeth_labs",
"https://megaeth.com/blog-news"
]
}
}
{
"capability": "universal",
"daLayer": [
"EigenDA"
],
"hostChain": {
"id": "ethereum",
"slug": "ethereum",
"name": "Ethereum"
},
"layer": "layer2",
"proofSystem": {
"type": "Optimistic"
"type": "Optimistic",
"name": "OP Kailua",
"zkCatalogId": "risc0",
"challengeProtocol": "Single-step"
},
"purposes": [
"Universal"
],
"stage": "Under review",
"vm": []
"reasonsForBeingOther": [
{
"label": "No DA bridge",
"shortDescription": "There is no data availability bridge",
"description": "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."
}
],
"stacks": [
"OP Stack"
],
"stage": "Not applicable",
"type": "Other",
"vm": [
"EVM"
]
}
{
"self": {
"stateValidation": {
"value": "Under Review",
"description": "This risk is currently under review.",
"sentiment": "UnderReview"
"value": "Fraud proofs (1R, ZK)",
"description": "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. Since the node source is not available, challengers cannot watch the chain independently.",
"sentiment": "bad",
"executionDelay": 302400,
"challengeDelay": 604800,
"initialBond": "0.00001",
"orderHint": null,
"secondLine": "10d 12h challenge + execution delay"
},
"dataAvailability": {
"value": "Under Review",
"description": "This risk is currently under review.",
"sentiment": "UnderReview"
},
"exitWindow": {
"value": "Under Review",
"description": "This risk is currently under review.",
"sentiment": "UnderReview"
"value": "None",
"description": "There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": -604800
},
"sequencerFailure": {
"value": "Under Review",
"description": "This risk is currently under review.",
"sentiment": "UnderReview"
},
"proposerFailure": {
"value": "Under Review",
"description": "This risk is currently under review.",
"sentiment": "UnderReview"
"value": "Cannot withdraw",
"description": "Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.",
"sentiment": "bad",
"orderHint": null
},
"dataAvailability": {
"value": "External",
"description": "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.",
"sentiment": "bad"
},
"sequencerFailure": {
"value": "Self sequence",
"description": "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.",
"sentiment": "good",
"orderHint": 43200,
"secondLine": "12h delay"
}
}
}
scalingDa+20-1
null
[
{
"layer": {
"value": "EigenDA",
"sentiment": "warning",
"description": "The data is posted to EigenDA which is a separate data availability layer developed by the Eigenlayer team. Only commitments to the data are published on an onchain inbox.",
"projectId": "eigenda"
},
"bridge": {
"value": "None",
"sentiment": "bad",
"description": "There is no bridge that can attest if the data has been made available.",
"orderHint": -2
},
"mode": {
"value": "Transaction data",
"secondLine": "Compressed"
}
}
]
scalingTechnology+171-1
{
"isUnderReview": true
"architectureImage": "opstack-optimium-superchain-opfp-kailua",
"dataAvailability": [
{
"name": "Data is posted to EigenDA",
"description": "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.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an unavailable transaction root.",
"isCritical": true
},
{
"category": "Funds can be lost if",
"text": "the data is not available on the external provider.",
"isCritical": true
}
],
"references": [
{
"title": "EigenDA Docs - Overview",
"url": "https://docs.eigenda.xyz/overview"
},
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0x00656C604FC470e6a566A695B74455e18a6D75D3#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exits",
"description": "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.",
"risks": [],
"references": [
{
"title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
}
]
},
{
"name": "Forced messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "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.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "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.",
"risks": [],
"references": [
{
"title": "Introducing EVM Equivalence",
"url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "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.\n\nProposals 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. \n\nProposals 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. \n\nThe **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.",
"references": [
{
"title": "'Sequencing' - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/design.html#sequencing"
},
{
"title": "Vanguard - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/parameters.html#vanguard-advantage"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "the vanguard exploits their vanguard advantage (36558901084y 8mo), halting the chain until they propose."
}
]
},
{
"title": "Challenges",
"description": "\nAny 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.\n\nIn 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: \n1. the proposal's challenge period of 7d has ended before a conflicting proposal was made\n2. the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)\n3. a conflicting sibling proposal is proven faulty\n\nProving 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.\n\nA 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).",
"references": [
{
"url": "https://boundless-xyz.github.io/kailua/dispute.html",
"title": "Disputes - Kailua Book"
}
]
},
{
"title": "Validity proofs",
"description": "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.\n\nThe 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.",
"references": [
{
"url": "https://risczero.com/blog/kailua-how-it-works",
"title": "Risc0 Kailua Docs"
},
{
"url": "https://github.com/risc0/risc0-ethereum/blob/main/contracts/version-management-design.md",
"title": "Verifier upgrade and deprecation - Kailua Docs"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "no challenger checks the published state."
},
{
"category": "Funds can be stolen if",
"text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector."
},
{
"category": "Funds can be frozen if",
"text": "a verifier needed for a given proof is paused by its permissioned owner."
}
]
}
]
},
"stateValidationImage": "megaeth"
}