{
"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 ## L2 Data Availability\n The Disperser collects the 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 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. \n This function is not used by the EigenDAServiceManager contract itself, but rather by L2 systems to prove inclusion of the blob in the EigenDAServiceManager contract, and that their trust assumptions (i.e., batch confirmation threshold) were as expected.\n ",
"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": "celo",
"name": "Celo",
"slug": "celo"
},
{
"id": "fuel",
"name": "Fuel Ignition",
"slug": "fuel"
},
{
"id": "mantle",
"name": "Mantle",
"slug": "mantle"
},
{
"id": "soon",
"name": "Soon Alpha Mainnet",
"slug": "soon"
}
],
"validators": {
"type": "static",
"count": 123
"count": 117
}
}
daBridge+8-4
{
"dac": {
"requiredMembers": 0,
"membersCount": 400
},
"daLayer": "eigenda",
"name": "DACert Verifier (EigenDA V1)",
"relayerType": {
"value": "Permissioned",
"sentiment": "warning",
"description": "Only whitelisted relayers can post attestations to this bridge."
"description": "EigenDA V1 uses whitelisted relayers to post attestations to the ServiceManager bridge through the confirmBatch() function."
},
"risks": {
"committeeSecurity": {
"value": "Permissioned",
"sentiment": "warning",
"description": "The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment.\n There are 123 operators currently registered in the committee, but entry or exit of members is partially controlled by a centralized entity.",
"description": "The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment.\n There are 117 operators currently registered in the committee, but entry or exit of members is partially controlled by a centralized entity.",
"orderHint": 1
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity."
}
},
"technology": {
"description": "\n## Architecture\n\n\n\nThe EigenDAServiceManager acts as a DA bridge smart contract verifying data availability claims from operators via signature verification.\nThe checkSignatures() function checks that the signature of all signers plus non-signers is equal to the registered quorum aggregated public key from the BLS registry. The quorum aggregated public key gets updated every time an operator is registered.\nThe bridge requires a threshold of signatures to be met before the data commitment is accepted. \nTo verify the threshold is met, the function takes the total stake at the reference block for the quorum from the StakeRegistry, and it subtracts the stake of non signers to get the signed stake.\nFinally, it checks that the signed stake over the total stake is more than the required stake threshold.\n\n\n\nAlthough thresholds are not enforced onchain by the confirmBatch method, the minimum thresholds that the disperser would need to reach before relaying the batch commitment to Ethereum are set to 55% of the registered stake for the ETH quorum and 55% for the EIGEN token quorum. Meeting these dispersal thresholds allows the system to tolerate up to 33% (quorum 1) and 33% (quorum 2) of the total stake being adversarial, achieving this with approximately 4.5 data redundancy. \nThe quorum thresholds are set on the EigenDAServiceManager contract and can be changed by the contract owner.\nThere is a maximum of 200 operators that can register for the ETH quorum and 200 for the EIGEN token quorum. Once the cap is reached, new operators must have 10% more weight than the lowest-weighted operator to join the active set. Entering the quorum is subject to the approval of the churn approver. Operators can be ejected from a quorum by the ejectors without delay should they violate the Service Legal Agreement (SLA). \n\n\nEjectors can eject maximum 33.33% of the total stake in a 7d window for the ETH quorum, and the same stake percentage over a 3d window for the EIGEN quorum.\nAn ejected operator can rejoin the quorum after 3d. \n ",
"description": "\n## Architecture\n\n\n\n### EigenDA V1 Bridge Architecture\nThe EigenDAServiceManager acts as a DA bridge smart contract verifying data availability claims from operators via signature verification.\nThe checkSignatures() function checks that the signature of all signers plus non-signers is equal to the registered quorum aggregated public key from the BLS registry. The quorum aggregated public key gets updated every time an operator is registered.\nThe bridge requires a threshold of signatures to be met before the data commitment is accepted. \nTo verify the threshold is met, the function takes the total stake at the reference block for the quorum from the StakeRegistry, and it subtracts the stake of non signers to get the signed stake.\nFinally, it checks that the signed stake over the total stake is more than the required stake threshold.\n\n\n\nAlthough thresholds are not enforced onchain by the confirmBatch method, the minimum thresholds that the disperser would need to reach before relaying the batch commitment to Ethereum are set to 55% of the registered stake for the ETH quorum and 55% for the EIGEN token quorum. Meeting these dispersal thresholds allows the system to tolerate up to 33% (quorum 1) and 33% (quorum 2) of the total stake being adversarial, achieving this with approximately 4.5 data redundancy. \nThe quorum thresholds are set on the EigenDAServiceManager contract and can be changed by the contract owner.\nThere is a maximum of 200 operators that can register for the ETH quorum and 200 for the EIGEN token quorum. Once the cap is reached, new operators must have 10% more weight than the lowest-weighted operator to join the active set. Entering the quorum is subject to the approval of the churn approver. Operators can be ejected from a quorum by the ejectors without delay should they violate the Service Legal Agreement (SLA). \n\n\nEjectors can eject maximum 33.33% of the total stake in a 7d window for the ETH quorum, and the same stake percentage over a 3d window for the EIGEN quorum.\nAn ejected operator can rejoin the quorum after 3d. \n ",
"references": [
{
"title": "EigenDA Integration Spec - Lifecycle Phases",
"url": "https://layr-labs.github.io/eigenda/integration/spec/5-lifecycle-phases.html#secure-dispersal"
},
{
"title": "EigenDA Registry Coordinator - Etherscan",
"url": "https://etherscan.io/address/0xdcabf0be991d4609096cce316df08d091356e03f"
},
{
"title": "EigenDA Service Manager - Etherscan",
"url": "https://etherscan.io/address/0x58fDE694Db83e589ABb21A6Fe66cb20Ce5554a07"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the relayer posts an invalid commitment and EigenDA operators do not make the data available for verification."
},
{
"category": "Funds can be frozen if",
"text": "excluding L2-specific DA fallback - the permissioned relayers are unable to submit DA commitments to the bridge contract."
},
{
"category": "Funds can be frozen if",
"text": "the bridge (EigenDAServiceManager) contract is paused by the pausers."
}
]
},
"usedIn": [],
"validationType": {
"value": "BLS Signature",
"description": "The DA attestation requires onchain BLS signatures verification to be accepted by the bridge, and the total stake of signers is verified to have reached the required threshold."
"description": "EigenDA V1 attestations require onchain BLS signatures verification through the EigenDAServiceManager contract. The total stake of signers is verified to have reached the required threshold."
}
}
{
"badges": [],
"description": "EigenDA V2 DACert Verifier provides certificate verification for EigenDA V2 with improved architecture where the sequencer acts as relayer.",
"links": {
"websites": [
"https://www.eigenda.xyz/"
],
"documentation": [
"https://docs.eigenda.xyz/overview"
],
"repositories": [
"https://github.com/Layr-Labs/eigenda"
],
"explorers": [
"https://blobs.eigenda.xyz/"
],
"socialMedia": [
"https://x.com/eigen_da"
]
}
}
colors+1-0
null
ecosystemColors+1-0
null
milestones+1-0
null
chainConfig+1-0
null
escrows+1-0
null
bridgeInfo+1-0
null
bridgeRisks+1-0
null
bridgeTechnology+1-0
null
scalingInfo+1-0
null
scalingStage+1-0
null
scalingRisks+1-0
null
scalingDa+1-0
null
scalingTechnology+1-0
null
daLayer+1-0
null
daBridge+59-0
{
"daLayer": "eigenda",
"name": "DACert Verifier (EigenDA V2)",
"relayerType": {
"value": "SelfRelay",
"sentiment": "good",
"description": "In EigenDA V2 secure integrations, the rollup batcher includes the DA certificate on L1, no separate third-party relayer is required."
},
"risks": {
"committeeSecurity": {
"value": "Permissioned",
"sentiment": "warning",
"description": "The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment.\n There are 117 operators currently registered in the committee, but entry or exit of members is partially controlled by a centralized entity.",
"orderHint": 1
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed."
},
"relayerFailure": {
"value": "Self propose",
"sentiment": "good",
"description": "Anyone can relay data availability commitments to the DA bridge. In case of current relayer failure, users can collect attestations from committee members and propose new data availability commitments to the DA bridge."
}
},
"technology": {
"description": "\n## EigenDA V2 Architecture\n\nEigenDA V2 introduces a more efficient architecture where the L2 sequencer acts as the relayer, eliminating the need for separate permissioned relayers:\n\n### Key Improvements\n- **Sequencer as Relayer**: The sequencer acts as the relayer, eliminating the need for separate permissioned relayers\n- **Direct Certificate Verification**: Multiple DACert Verifier contracts handle different certificate versions (V2, V3). These contracts read operator/state metadata via EigenDA and EigenLayer core contracts (incl. ServiceManager components) and verify signatures and stake thresholds.\n- **Version-Specific Verification**: Each certificate version has a corresponding verifier contract that validates the specific certificate format and cryptographic proofs\n\n### Certificate Types and Verifiers\nEigenDA V2 supports multiple certificate formats:\n\n- **V2 Certificates**: Contain blob inclusion info, batch headers, and non-signer stakes with signatures. Verified through EigenDACertVerifierV2 contracts.\n- **V3 Certificates**: Similar structure to V2 but with reordered fields for optimization. Verified through EigenDACertVerifierV3 contracts.\n\n### Verification Process\n1. **Certificate Construction**: The EigenDA client constructs certificates from BlobStatusReply data received from the disperser\n2. **Version Detection**: The certificate version is determined from the commitment structure \n3. **Verifier Selection**: The appropriate DACert Verifier contract is selected based on the certificate version using the EigenDACertVerifierRouter\n4. **Onchain Verification**: The verifier contract's checkDACert function validates the certificate against operator signatures and stake thresholds\n\n### Secure Dispersal Flow\nBased on the [EigenDA Integration Spec](https://layr-labs.github.io/eigenda/integration/spec/5-lifecycle-phases.html#secure-dispersal):\n\n1. EigenDA Client converts raw payload bytes into a blob\n2. Client fetches the appropriate EigenDACertVerifier contract address using the router\n3. Client submits blob request to disperser and polls for BlobStatusReply\n4. Once confirmation thresholds are met, client constructs the DACert from the reply\n5. Client calls the verifier's checkDACert function for onchain verification\n6. Based on verification status, client either returns the certificate or initiates failover\n\n### Router-Based Verifier Selection\nEigenDA V2 uses the EigenDACertVerifierRouter to dynamically select the appropriate verifier contract:\n- The router maps certificate versions to their corresponding verifier contracts\n- This allows for seamless upgrades and support for multiple certificate formats\n- The client queries the router using the latest block number to get the verifier for the reference block\n\nThis architecture provides improved throughput and eliminates single points of failure while maintaining the same security guarantees as V1.\n ",
"references": [
{
"title": "EigenDA Integration Spec - Lifecycle Phases",
"url": "https://layr-labs.github.io/eigenda/integration/spec/5-lifecycle-phases.html#secure-dispersal"
},
{
"title": "EigenDA - Documentation",
"url": "https://docs.eigenda.xyz/overview"
},
{
"title": "EigenDA Disperser - Source Code",
"url": "https://github.com/Layr-Labs/eigenda/blob/2ed86a0c1dd730b56c8235031c19e08a9837bde8/disperser/batcher/batcher.go"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an invalid certificate and EigenDA operators do not make the data available for verification."
},
{
"category": "Funds can be frozen if",
"text": "the EigenDACertVerifierRouter fails to provide correct verifier contract addresses."
}
]
},
"usedIn": [],
"validationType": {
"value": "BLS Signature",
"description": "EigenDA V2 certificates require onchain BLS signatures verification through dedicated DACert Verifier contracts. Each certificate version corresponds to a specific verifier that validates the certificate format and proofs."
}
}