{
"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": "rise",
"name": "Rise",
"daTrackingConfig": [
{
"type": "eigen-da",
"sinceTimestamp": 1767607200,
"customerId": "0x78d5974216f751eb328018f003067f77e8be2fc4"
}
]
},
{
"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\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\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": "megaeth",
"name": "MegaETH",
"slug": "megaeth"
},
{
"id": "roninnetwork",
"name": "Ronin",
"slug": "ronin-network"
},
{
"id": "soon",
"name": "Soon Alpha Mainnet",
"slug": "soon"
}
],
"validators": {
"type": "static",
"count": 91
}
}
[REMOVED]ronin-network+0-140
id+0-1
"ronin-network"
slug+0-1
"ronin-network"
name+0-1
"Ronin"
shortName+0-1
null
aliases+0-4
[
"Sky Mavis",
"Axie Infinity"
]
addedAt+0-1
1754639625
statuses+0-3
{
"unverifiedContracts": []
}
display+0-25
{
"badges": [],
"description": "Ronin is an Ethereum L2 running the OP rollup stack built for gaming. The network's key innovation is offering high throughput and low fees optimized for NFT transactions and in-game economies, powering ecosystems like Axie Infinity.",
"links": {
"websites": [
"https://roninchain.com/"
],
"bridges": [
"https://app.roninchain.com/bridge"
],
"documentation": [
"https://docs.roninchain.com/"
],
"repositories": [
"https://github.com/axieinfinity"
],
"explorers": [
"https://app.roninchain.com/explorer"
],
"socialMedia": [
"https://twitter.com/Ronin_Network",
"https://discord.gg/roninnetwork"
]
}
}
{
"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": "OPStack",
"type": "Stack",
"name": "Built on OP Stack",
"description": "The project is built on the OP Stack",
"action": {
"type": "scalingFilter",
"id": "stack",
"value": "OP Stack"
}
},
{
"id": "MigratedFromL1",
"type": "Other",
"name": "Migrated from L1 to Ethereum L2",
"description": "This project has migrated from being a standalone L1 blockchain to an Ethereum L2",
"action": {
"type": "scalingFilter",
"id": "other",
"value": "Migrated from L1 to Ethereum L2"
}
},
{
"id": "Conduit",
"type": "RaaS",
"name": "Conduit",
"description": "This project was deployed via the rollup-as-a-service provider Conduit",
"action": {
"type": "scalingFilter",
"id": "raas",
"value": "Conduit"
}
}
],
"description": "Ronin is an Ethereum Optimium based on the OP Stack, optimized for gaming and NFT applications. It migrated from an independent sidechain to a Layer 2 in May 2026, using EigenDA for data availability and keeping RON as the custom gas token.",
"links": {
"websites": [
"https://roninchain.com/"
],
"bridges": [
"https://app.roninchain.com/bridge"
],
"documentation": [
"https://docs.roninchain.com/"
],
"repositories": [
"https://github.com/ronin-chain/ronin",
"https://github.com/axieinfinity"
],
"explorers": [
"https://app.roninchain.com/explorer"
],
"socialMedia": [
"https://twitter.com/Ronin_Network",
"https://discord.gg/roninnetwork",
"https://blog.roninchain.com/"
]
}
}
colors+1-0
null
ecosystemColors+1-0
null
milestones+9-0
[
{
"title": "Ronin migrates to an Ethereum L2",
"url": "https://blog.roninchain.com/p/ronin-is-coming-home-to-ethereum",
"date": "2026-05-12T00:00:00.00Z",
"description": "Ronin hard-forks at block 55,577,490 to become an OP Stack Optimium using EigenDA.",
"type": "general"
}
]
{
"capability": "universal",
"daLayer": [
"EigenDA"
],
"hostChain": {
"id": "ethereum",
"slug": "ethereum",
"name": "Ethereum"
},
"layer": "layer2",
"purposes": [
"Universal"
],
"raas": "Conduit",
"reasonsForBeingOther": [
{
"label": "No proofs",
"shortDescription": "The proof system isn't fully functional",
"description": "Projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds."
},
{
"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": "Stage 0",
"type": "Other",
"vm": [
"EVM"
]
}
scalingStage+104-0
{
"missing": {
"nextStage": "Stage 1",
"requirements": [
"Users' withdrawals can be censored by the permissioned operators.",
"Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring.",
"The Security Council is not properly set up.",
"No secure onchain DA verifier is integrated on L1, so DA attestations cannot be independently verified by challengers.",
"The DA verifier is upgradeable with less than 7d independent exit window.",
"The DA layer does not meet minimum decentralization requirements (DAC <5 external members, or no attestation verifier for an external DA chain)."
],
"principle": "Compromising ≥75% of the Security Council to push a malicious upgrade, or sequencer+DA-committee collusion to withhold data and finalize invalid state roots, should be the only ways (other than bugs) to steal funds or block withdrawals indefinitely."
},
"stage": "Stage 0",
"summary": [
{
"stage": "Stage 0",
"requirements": [
{
"satisfied": true,
"description": "The project self-identifies as a Validium or Optimium."
},
{
"satisfied": true,
"description": "State roots are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "A complete and functional proof system (fraud or validity proofs) is deployed."
},
{
"satisfied": false,
"description": "DA is attested solely by the sequencer, which can withhold data unilaterally."
},
{
"satisfied": true,
"description": "A source-available node exists that can reconstruct the L2 state when DA is accessible. Please note that the L2BEAT team has not verified the validity of the node source code. [View code](https://github.com/conduitxyz/ronin-migration-reth-docker)"
},
{
"satisfied": false,
"description": "Fraud proof submission is not sufficiently decentralized."
}
]
},
{
"stage": "Stage 1",
"requirements": [
{
"satisfied": false,
"description": "Users' withdrawals can be censored by the permissioned operators."
},
{
"satisfied": false,
"description": "Upgrades executed by actors with more centralized control than a Security Council provide less than 7d for users to exit if the permissioned operator is down or censoring."
},
{
"satisfied": false,
"description": "The Security Council is not properly set up."
},
{
"satisfied": false,
"description": "No secure onchain DA verifier is integrated on L1, so DA attestations cannot be independently verified by challengers."
},
{
"satisfied": false,
"description": "The DA verifier is upgradeable with less than 7d independent exit window."
},
{
"satisfied": false,
"description": "The DA layer does not meet minimum decentralization requirements (DAC <5 external members, or no attestation verifier for an external DA chain)."
}
],
"principle": {
"satisfied": false,
"description": "Compromising ≥75% of the Security Council to push a malicious upgrade, or sequencer+DA-committee collusion to withhold data and finalize invalid state roots, should be the only ways (other than bugs) to steal funds or block withdrawals indefinitely."
}
},
{
"stage": "Stage 2",
"requirements": [
{
"satisfied": false,
"description": "Fraud proof submission is open only to whitelisted actors."
},
{
"satisfied": false,
"description": "Upgrades unrelated to onchain provable bugs, including upgrades to the DA verifier, provide less than 30d to exit."
},
{
"satisfied": false,
"description": "The Security Council's actions are not confined to onchain provable bugs."
},
{
"satisfied": false,
"description": "The DA verifier (and related contracts) is upgradeable with less than 30d independent exit window."
},
{
"satisfied": false,
"description": "The DA mechanism relies on reputational security alone; no staked assets are at risk for DA misbehavior or slashable < TVS."
}
]
}
]
}
scalingRisks+38-0
{
"self": {
"stateValidation": {
"value": "Fraud proofs (INT)",
"description": "Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. Only one entity is currently allowed to propose and submit challenges, as only permissioned games are currently allowed.",
"executionDelay": 302400,
"challengeDelay": 302400,
"sentiment": "bad",
"orderHint": null,
"initialBond": "0.0",
"secondLine": "7d challenge + execution delay"
},
"exitWindow": {
"value": "None",
"description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"orderHint": -604800
},
"proposerFailure": {
"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-0
[
{
"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+166-0
{
"architectureImage": "opstack-optimium-superchain-opfp",
"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.",
"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/0x003A7A2d3129838Adb01c8d9b7DA62Ac6Ec27961#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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 3d 12h 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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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/0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B#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"
}
]
},
{
"name": "External bridge architecture",
"description": "The May 2026 L2 migration deployed the OP Stack canonical bridge (OptimismPortal2 and L1StandardBridge) but did not migrate user funds into it; it is currently empty. User assets are custodied on two separate L1 paths, neither of which is the canonical bridge analyzed on this page: (1) Chainlink CCIP TokenPools, the active bridge since April 2025, securing 12 tokens including AXS, USDC, WETH, WBTC (new contract), YGG, PIXEL and SLP via Chainlink DON attestations and the Risk Management Network; (2) the legacy MainchainGateway, deprecated in April 2025 but still holding residual balances (legacy WBTC, ETH backing of legacy WETH, dust), withdrawable through the Ronin BridgeOperator stake-weighted multisig. Sky Mavis has not announced a plan to migrate liquidity into the OP Stack bridge.",
"risks": [],
"references": [
{
"title": "MainchainGateway - Etherscan",
"url": "https://etherscan.io/address/0x64192819Ac13Ef72bF6b5AE239AC672B43a9AF08"
},
{
"title": "Ronin Bridge to Chainlink CCIP migration - Ronin Blog",
"url": "https://blog.roninchain.com/p/the-ronin-bridge-chainlink-ccip-migration"
}
]
},
{
"name": "Proof system cannot execute for this chain",
"description": "The dispute games on this chain commit to the op-program v1.3.1 prestate (0x038512e0…6764d54c). That binary embeds the superchain-registry snapshot at commit 42bd03ba8313 (2024-08-21), which lists 17 chain IDs and does not include Ronin (chainId 2020). If a dispute game were stepped through to the VM, op-program's RollupConfigByChainID(2020) would not find a rollup config and would panic, producing an invalid output state — any claim (honest or fraudulent) could then be \"disproven\" against the panic. Users are not exposed today because the respected game type is PermissionedDisputeGame: only the proposer can create state proposals and only proposer/challenger can move or step. The proof system therefore reduces to an operator-attested delay timer rather than an adversarial fraud-proof. Fix would require redeploying games with either an updated registry snapshot or a chain-specific prestate.",
"risks": [],
"references": [
{
"title": "absolutePrestate hash registered in superchain-registry as op-program v1.3.1",
"url": "https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-prestates.toml"
},
{
"title": "op-program v1.3.1 release (commit e3c2f04, 2024-08-23)",
"url": "https://github.com/ethereum-optimism/optimism/releases/tag/op-program%2Fv1.3.1"
},
{
"title": "superchain-registry snapshot pinned at op-program v1.3.1 build (42bd03ba8313)",
"url": "https://github.com/ethereum-optimism/superchain-registry/blob/42bd03ba8313/chainList.json"
}
]
}
],
"stateValidation": {
"description": "Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.",
"categories": [
{
"title": "State root proposals",
"description": "Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the `create` function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.",
"references": [
{
"title": "OP stack specification: Fault Dispute Game",
"url": "https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#fault-dispute-game"
}
]
},
{
"title": "Challenges",
"description": "Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the `defend` or `attack` functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with [full concurrency](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a). Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see [freeloader claims](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html#freeloader-claims)), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 0s right before the last depth. The maximum clock extension that a top level claim can get is therefore 0s. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers' stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks ([Spearbit 5.1.3](https://github.com/ethereum-optimism/optimism/blob/develop/docs/security-reviews/2024_08_Fault-Proofs-No-MIPS_Spearbit.pdf)).",
"references": [
{
"title": "Fraud Proof Wars: OPFP",
"url": "https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a"
}
]
}
]
},
"stateValidationImage": "opfp"
}