{
"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 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
}
}
ethereum+5-0
daBridge+5-0
{
"daLayer": "ethereum",
"name": "Enshrined Bridge",
"risks": {
"daBridge": {
"value": "Enshrined",
"sentiment": "good",
"description": "Rollup users have access to all the data, as it is posted onchain on the consensus layer. On the execution layer, the rollup relies on blob data commitment (versioned hashes), which are accessible through the BLOBHASH opcode. \nThe rollup smart contracts can use these blob commitments during state transition validation to reference blobs during proof verification, without requiring direct access to the raw blob data.\n "
},
"callout": "Unlike non-enshrined DA bridges, it does not place any honesty\n assumption on an external committee that provides data availability\n attestations to the DA bridge. From the rollup perspective,\n Ethereum's canonical chain cannot contain unavailable data\n commitments as full nodes self-verify the data availability of each\n block, discarding blocks with unavailable data. The rollup state\n validating bridge has access to all the data, as it is posted on chain."
},
"technology": {
"description": "\n ## Enshrined Bridge\n The DA bridge on Ethereum is enshrined, meaning that blob data is directly accessible on the consensus layer, with data availability guaranteed by the network's inherent consensus rules. \n If a block contains unavailable data, full nodes will reject it, causing the chain to fork away from that block. This ensures data availability without requiring additional trust assumptions. \n In contrast, external DA providers must rely on data availability attestations from the external validator set, introducing an extra layer of trust on the majority of validators.\n "
},
"usedIn": [
{
"id": "abstract",
"name": "Abstract",
"slug": "abstract"
},
{
"id": "adi",
"name": "ADI Chain",
"slug": "adi"
},
{
"id": "arbitrum",
"name": "Arbitrum One",
"slug": "arbitrum"
},
{
"id": "arenaz",
"name": "Arena-Z",
"slug": "arenaz"
},
{
"id": "base",
"name": "Base Chain",
"slug": "base"
},
{
"id": "blast",
"name": "Blast",
"slug": "blast"
},
{
"id": "bob",
"name": "BOB",
"slug": "bob"
},
{
"id": "bobanetwork",
"name": "Boba Network",
"slug": "bobanetwork"
},
{
"id": "cartesi-prt-honeypot-v2",
"name": "Cartesi PRT Honeypot v2",
"slug": "cartesi-prt-honeypot-v2"
},
{
"id": "dbk",
"name": "DeBank Chain",
"slug": "dbk"
},
{
"id": "deri",
"name": "Deri",
"slug": "deri"
},
{
"id": "ethernity",
"name": "Epic Chain",
"slug": "epicchain"
},
{
"id": "ethscriptions",
"name": "Ethscriptions",
"slug": "ethscriptions"
},
{
"id": "facet",
"name": "Facet v1",
"slug": "facet"
},
{
"id": "forknet",
"name": "Forknet",
"slug": "forknet"
},
{
"id": "hashkey",
"name": "HashKey Chain",
"slug": "hashkey"
},
{
"id": "hemi",
"name": "Hemi",
"slug": "hemi"
},
{
"id": "ink",
"name": "Ink",
"slug": "ink"
},
{
"id": "jovay",
"name": "Jovay",
"slug": "jovay"
},
{
"id": "katana",
"name": "Katana",
"slug": "katana"
},
{
"id": "lighter",
"name": "Lighter",
"slug": "lighter"
},
{
"id": "linea",
"name": "Linea",
"slug": "linea"
},
{
"id": "lisk",
"name": "Lisk",
"slug": "lisk"
},
{
"id": "loopring",
"name": "Loopring",
"slug": "loopring"
},
{
"id": "mantle",
"name": "Mantle",
"slug": "mantle"
},
{
"id": "metal",
"name": "Metal",
"slug": "metal"
},
{
"id": "metis",
"name": "Metis Andromeda",
"slug": "metis"
},
{
"id": "mint",
"name": "Mint",
"slug": "mint"
},
{
"id": "mode",
"name": "Mode Network",
"slug": "mode"
},
{
"id": "morph",
"name": "Morph",
"slug": "morph"
},
{
"id": "optimism",
"name": "OP Mainnet",
"slug": "op-mainnet"
},
{
"id": "phala",
"name": "Phala",
"slug": "phala"
},
{
"id": "polynomial",
"name": "Polynomial",
"slug": "polynomial"
},
{
"id": "r0ar",
"name": "R0ar",
"slug": "r0ar"
},
{
"id": "race",
"name": "Race Network",
"slug": "race"
},
{
"id": "scroll",
"name": "Scroll",
"slug": "scroll"
},
{
"id": "settlus",
"name": "Settlus",
"slug": "settlus"
},
{
"id": "shape",
"name": "Shape",
"slug": "shape"
},
{
"id": "soneium",
"name": "Soneium",
"slug": "soneium"
},
{
"id": "starknet",
"name": "Starknet",
"slug": "starknet"
},
{
"id": "superseed",
"name": "Superseed",
"slug": "superseed"
},
{
"id": "swan",
"name": "Swan Chain",
"slug": "swan"
},
{
"id": "swell",
"name": "Swellchain",
"slug": "swell"
},
{
"id": "taiko",
"name": "Taiko Alethia",
"slug": "taiko"
},
{
"id": "unichain",
"name": "Unichain",
"slug": "unichain"
},
{
"id": "worldchain",
"name": "World Chain",
"slug": "world"
},
{
"id": "xlayer",
"name": "X Layer",
"slug": "xlayer"
},
{
"id": "zeronetwork",
"name": "ZERO Network",
"slug": "zeronetwork"
},
{
"id": "zircuit",
"name": "Zircuit",
"slug": "zircuit"
},
{
"id": "aztec",
"name": "Zk.Money v1 (Aztec v1)",
"slug": "aztecv1"
},
{
"id": "zksync2",
"name": "ZKsync Era",
"slug": "zksync-era"
},
{
"id": "zksync",
"name": "ZKsync Lite",
"slug": "zksync-lite"
},
{
"id": "zora",
"name": "Zora",
"slug": "zora"
}
]
}
mantle+126-57
display+6-6
{
"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",
"id": "EthereumBlobs",
"type": "DA",
"name": "EigenDA",
"description": "This project is posting its data to EigenDA",
"name": "Ethereum with blobs",
"description": "This project is posting its data to Ethereum as blobs",
"action": {
"type": "publicDaHighlight",
"slug": "eigenda"
"slug": "ethereum"
}
},
{
"id": "OPSuccinct",
"type": "Stack",
"name": "Built on the OP Succinct stack",
"description": "The project is built on the OP Succinct stack"
}
],
"description": "Mantle is a modular general-purpose validium with a protocol design philosophy that aims to offer users a less costly and more user-friendly experience, provide developers with a simpler and more flexible development environment, and deliver a comprehensive set of infrastructure for the next wave of mass-adopted dApps.",
"description": "Mantle is a ZK Rollup based on the OP Stack that uses SP1 proofs for state validation. It aims to offer users a less costly and more user-friendly experience, provide developers with a simpler and more flexible development environment, and deliver a comprehensive set of infrastructure for the next wave of mass-adopted dApps.",
"links": {
"websites": [
"https://mantle.xyz/"
],
"bridges": [
"https://bridge.mantle.xyz"
],
"documentation": [
"https://docs-v2.mantle.xyz/"
],
"explorers": [
"https://explorer.mantle.xyz/"
],
"repositories": [
"https://github.com/mantlenetworkio"
],
"socialMedia": [
"https://discord.gg/0xMantle",
"https://twitter.com/0xMantle",
"https://x.com/Mantle_Official",
"https://medium.com/0xmantle",
"https://t.me/mantlenetwork"
],
"other": [
"https://growthepie.com/chains/mantle"
]
}
}
milestones+7-0
[
{
"title": "Migration to Ethereum blobs",
"url": "https://etherscan.io/tx/0x7234302dd8c359a14681a03f1d948369d45c00fd4a61683c449839f051e4ddb8",
"date": "2026-01-21T00:00:00.00Z",
"description": "Mantle moves to the Rollup category by switching data availability from EigenDA to Ethereum blobs.",
"type": "general"
},
{
"title": "Upgrade to OP Succinct",
"url": "https://x.com/Mantle_Official/status/1967936628678430965",
"date": "2025-09-16T00:00:00.00Z",
"description": "Mantle upgrades to OP Succinct, integrating ZK proofs for state validation.",
"type": "general"
},
{
"title": "Move to EigenDA",
"url": "https://github.com/mantlenetworkio/mantle-v2/releases/tag/v1.1.1",
"date": "2025-03-19T00:00:00.00Z",
"description": "Mantle deactivates MantleDA and data availability migrates to EigenDA.",
"type": "general"
},
{
"title": "Mainnet Launch",
"url": "https://www.mantle.xyz/blog/announcements/mantle-network-mainnet-alpha",
"date": "2023-07-14T00:00:00.00Z",
"description": "Mantle is live on mainnet.",
"type": "general"
},
{
"title": "Mainnet v2 Tectonic Upgrade",
"url": "https://www.mantle.xyz/blog/announcements/mantle-completes-mainnet-v2-tectonic-upgrade",
"date": "2024-03-15T00:00:00.00Z",
"description": "Mantle completes Mainnet v2 Tectonic Upgrade.",
"type": "general"
},
{
"title": "MNT token migration begins",
"url": "https://www.mantle.xyz/blog/announcements/bit-to-mnt-user-guide",
"date": "2023-07-11T00:00:00.00Z",
"description": "Users can exchange their BIT tokens to MNT tokens.",
"type": "general"
}
]
scalingInfo+3-10
{
"capability": "universal",
"daLayer": [
"EigenDA"
"Ethereum"
],
"hostChain": {
"id": "ethereum",
"slug": "ethereum",
"name": "Ethereum"
},
"layer": "layer2",
"proofSystem": {
"type": "Validity",
"zkCatalogId": "sp1"
},
"purposes": [
"Universal"
],
"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",
"stage": "Stage 0",
"type": "ZK Rollup",
"vm": [
"EVM"
]
}
scalingStage+66-1
{
"stage": "NotApplicable"
"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."
],
"principle": "Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
},
"stage": "Stage 0",
"summary": [
{
"stage": "Stage 0",
"requirements": [
{
"satisfied": true,
"description": "A complete and functional proof system is deployed."
},
{
"satisfied": true,
"description": "The project calls itself a rollup."
},
{
"satisfied": true,
"description": "State roots are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "Inputs for the state transition function are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code. [View code](https://github.com/succinctlabs/op-succinct/)"
}
]
},
{
"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."
}
],
"principle": {
"satisfied": false,
"description": "Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window."
}
},
{
"stage": "Stage 2",
"requirements": [
{
"satisfied": false,
"description": "Upgrades unrelated to onchain provable bugs provide less than 30d to exit."
},
{
"satisfied": false,
"description": "The Security Council's actions are not confined to onchain provable bugs."
}
]
}
]
}
scalingRisks+4-3
{
"self": {
"stateValidation": {
"value": "Validity proofs (ST, SN)",
"description": "STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.",
"sentiment": "good",
"orderHint": null,
"executionDelay": 43200,
"secondLine": "12h execution delay"
},
"exitWindow": {
"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": -43200
},
"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. Sequencer transaction data roots are not checked against the ServiceManager DA bridge data roots onchain.",
"sentiment": "bad"
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"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+9-8
[
{
"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"
"value": "Ethereum",
"secondLine": "Blobs or Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata or blobs.",
"projectId": "ethereum"
},
"bridge": {
"value": "None",
"sentiment": "bad",
"description": "There is no bridge that can attest if the data has been made available.",
"orderHint": -2
"value": "Enshrined",
"sentiment": "good",
"description": "The validating bridge has access to all the data, as it is posted onchain.",
"projectId": "ethereum"
},
"mode": {
"value": "Transaction data",
"secondLine": "Compressed"
}
}
]
scalingTechnology+10-16
{
"architectureImage": "opstack-optimium-opfp-opsuccinct",
"architectureImage": "opstack-rollup-opfp-opsuccinct",
"dataAvailability": [
{
"name": "Data is posted to EigenDA",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. Since the ServiceManager bridge is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments. Mantle uses Hokulea, a Rust implementation that provides EigenDA blob derivation for OP stack chains.",
"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": [
{
"url": "https://docs.eigenda.xyz/overview",
"title": "EigenDA Docs - Overview"
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"url": "https://github.com/Layr-Labs/hokulea",
"title": "Hokulea - EigenDA blob derivation library"
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0xFFEEDDCcBbAA0000000000000000000000000000#code"
},
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
"title": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe1399f54ba2597b4EaDA9E3450c34D393fb131A7#code"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an unavailable transaction root.",
"isCritical": true
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "OptimismPortal.sol - source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe1399f54ba2597b4EaDA9E3450c34D393fb131A7#code"
},
{
"title": "OptimismPortal.sol - source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0xe1399f54ba2597b4EaDA9E3450c34D393fb131A7#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": "OptimismPortal.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0xe1399f54ba2597b4EaDA9E3450c34D393fb131A7#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": "Validity proofs",
"description": "Each update to the system state 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 Through the SuccinctL2OutputOracle, the system also allows to switch to an optimistic mode, in which no proofs are required and a challenger can challenge the proposed output state root within the finalization period.",
"references": [
{
"url": "https://succinctlabs.github.io/op-succinct/architecture.html",
"title": "Op-Succinct architecture"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "in non-optimistic mode, the validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "optimistic mode is enabled and no challenger checks the published state."
},
{
"category": "Funds can be frozen if",
"text": "the permissioned proposer fails to publish state roots to the L1."
}
]
}
]
},
"stateValidationImage": "opsuccinct"
}
livenessInfo+1-1
{
"explanation": "Mantle is a ZK rollup that posts transaction data to EigenDA. For a transaction to be considered final, it has to be posted within a tx batch on L1 that links to a previous finalized batch. If the previous batch is missing, transaction finalization can be delayed up to 12h or until it gets published. The state root gets confirmed 12h after it has been posted.",
"explanation": "Mantle is a ZK rollup that posts transaction data to the L1. For a transaction to be considered final, it has to be posted within a tx batch on L1 that links to a previous finalized batch. If the previous batch is missing, transaction finalization can be delayed up to 12h or until it gets published. The state root gets confirmed 12h after it has been posted.",
"warnings": {
"stateUpdates": "Please note, the state is not finalized until the finalization period passes."
}
}