EigenDA Protocol Contracts

This page describes EigenDA contracts that are managed by EigenDA related actors (see the exact roles).

Warning: This page is incomplete and a work in progress as we are undergoing refactors of our contracts as well as some protocol upgrades. The details will change, but the information contained here should at least help to understand the important concepts.

Overview

Middleware Contracts

We make use of eigenlayer-middleware contracts, which are fully documented here and described here. These contracts provide standard interfacing logic for operator state management and AVS representation.

Middleware Vendored Contracts

Some of the middleware contracts (e.g, EjectionsManager, RegistryCoordinator) have been directly vendored into the EigenDA project with minor modifications made.

EigenDA Specific Contracts

The smart contracts can be found in our repo, and the deployment addresses on different chains can be found in the Networks section of our docs.

Integration Contracts

For EigenDA-related contracts that are managed by rollups, see the rollup managed contracts page.

The EigenDA team maintains one customer-facing contract, EigenDACertVerifier. However, using this contract directly is not recommended. The EigenDACertVerifier includes a certVersion parameter that, if upgraded without corresponding updates to a rollup’s offchain code, can lead to liveness outages. Relying on this contract places a rollup’s safety and liveness on EigenDA governance, which is generally discouraged.

Contracts Overview

EigenDADirectory

Description

This contract serves as the central discovery and reference point for all contracts composing the EigenDA system. It implements a lightweight namespace resolution protocol in which human-readable string keys are mapped to EigenDA contract addresses.

Access Mgmt

• Ownable role that can do unilateral entry key modifications

Offchain Usage

This dynamic naming pattern requires off-chain management of canonical contract keys, allowing clients and services to retrieve on-chain system context from a single directory contract reference rather than requiring every contract address to be hard-coded or passed through environment configuration.

EigenDAServiceManager

Description Used for onchain AVS registration with the EigenLayer protocol, EigenDA V1 batching, storing protocol params, rewards distribution, and referencing EigenDA protocol contracts:

• Inherits the ServiceManagerBase for operator registration and rewards distribution.
• Manages batch settlement roles with callable function (i.e, confirmBatch) that allows for EigenDA V1 batches to be confirmed and settled into a storage commitment sequence.
• Stores protocol params (i.e, BLOCK_STALE_MEASURE, BLOCK_STORE_DURATION) for offchain ingestion by DA validator nodes.
• Stores non-callable references to other EigenDA protocol contracts in storage (i.e, DisperserRegistry, ThresholdRegistry, RelayRegistry, StakeRegistry, PaymentVault).

Access Mgmt

• Pauser role that can halt EigenDA V1 batch settlement
• Ownable role that can modify batch confirmer EOA allow-list, AVS metadata, RewardsClaimee, and RewardsInitiator
• RegistryCoordinator role that can register/de-register operators through routed calls to the AVSDirectory (i.e, RegistryCoordinator -> EigenDAServiceManager -> AVSDirectory)
• RewardsInitiator role that can create operator directed and general AVS rewards via routed calls to the RewardsCoordinator contract (i.e, RewardsInitiator -> EigenDAServiceManager -> RewardsCoordinator)

Offchain Usage

TODO

EigenDAThresholdRegistry

Description

The EigenDAThresholdRegistry contains two sets of protocol parameters:

/// @notice mapping of blob version id to the params of the blob version
mapping(uint16 => VersionedBlobParams) public versionedBlobParams;
struct VersionedBlobParams {
    uint32 maxNumOperators;
    uint32 numChunks;
    uint8 codingRate;
}

/// @notice Immutable security thresholds for quorums
SecurityThresholds public defaultSecurityThresholdsV2;
struct SecurityThresholds {
    uint8 confirmationThreshold;
    uint8 adversaryThreshold;
}

The securityThresholds are currently immutable. Confirmation and adversary thresholds are sometimes also referred to as liveness and safety thresholds:

• Confirmation Threshold (aka liveness threshold): minimum percentage of stake which an attacker must control in order to mount a liveness attack on the system.
• Adversary Threshold (aka safety threshold): total percentage of stake which an attacker must control in order to mount a first-order safety attack on the system.

Their default values are currently set as:

defaultSecurityThresholdsV2 = {
    confirmationThreshold = 55,
    adversaryThreshold = 33,
}

A new BlobParam version is rarely introduced by the EigenDA Foundation Governance. When dispersing a blob, rollups explicitly specify the version they wish to use. Currently, only version 0 is defined, with the following parameters (reference):

versionedBlobParams[0] = {
    maxNumOperators =  3537,
    numChunks = 8192,
    codingRate = 8,
}

The five parameters are intricately related by this formula which is also verified onchain by the verifyBlobSecurityParams function:

$$numChunks\cdot (1-\frac{100}{\gamma \ast codingRate})\ge maxNumOperators$$

where $\gamma =confirmationThreshold-adversaryThreshold$

EigenDARelayRegistry

Description

Contains EigenDA network registered Relays' Ethereum address and DNS hostname or IP address. BlobCertificates contain relayKeys, which can be transformed into that relay's URL by calling relayKeyToUrl.

Access Mgmt

• Ownable role that can register new relay entries

Offchain Usage

TODO

EigenDADisperserRegistry

Description

Contains EigenDA network registered Dispersers' Ethereum address. The EigenDA Network currently only supports a single Disperser, hosted by EigenLabs. The Disperser's URL is currently static and unchanging, and can be found on our docs site in the Networks section.

Access Mgmt

• Ownable role that can register new dispersers

Offchain Usage

TODO

PaymentVault

Description

Payment contract used to escrow on-demand funds, hold user reservations, and define global payment parameters used by the network (i.e, globalSymbolsPerPeriod, reservationPeriodInterval, globalRatePeriodInterval).

Access Mgmt

• Ownable role that can set payment reservations

Offchain Usage

TODO

PauserRegistry

Description Manages a stateful mapping of pausers that can be arbitrarily added or revoked. This contract is assumed to be deployed immutably. The pauser mapping is checked by caller:

• Mapping checked as prerequisite for pausing batch confirmation logic in EigenDAServiceManager
• Mapping checked as prerequisite for pausing operator state update logic in RegistryCoordinator

Access Mgmt

• Unpauser (or admin) role that can set / remove existing pausers

Offchain Usage

TODO

BLSApkRegistry

Description This contract stores each operator's BLS public key as well as per quorum aggregate public keys which are only updatable by the RegistryCoordinator.

Access Mgmt

• RegistryCoordinator role that can invoke aggregate key updates via the registration/de-registration of operators

Offchain Usage

TODO

IndexRegistry

Description Maintains an ordered, historically versioned list of operators for each quorum, allowing the RegistryCoordinator to register or deregister operators while preserving full block-by-block history of operator counts and index assignments. It provides efficient read functions to reconstruct the operator set at any block.

Access Mgmt

• RegistryCoordinator role that makes stateful updates when registering / deregistering quorum operators

Offchain Usage

TODO

StakeRegistry

Description Stores stake updates bounded by block number and quorum strategy:

    struct StakeUpdate {
        // the block number at which the stake amounts were updated and stored
        uint32 updateBlockNumber;
        // the block number at which the *next update* occurred.
        /// @notice This entry has the value **0** until another update takes place.
        uint32 nextUpdateBlockNumber;
        // stake weight for the quorum
        uint96 stake;
    }

Access Mgmt

• Ownable role that can deploy and modify staking strategies
• RegistryCoordinator role that makes stateful updates when registering / deregistering quorum operators

Offchain Usage

TODO

SocketRegistry

Description Stores stateful mapping of operator ID => socket where socket is the operator's DNS hostname.

Access Mgmt

• RegistryCoordinator role that makes stateful updates when registering / deregistering quorum operators

Offchain Usage

TODO

OperatorStateRetriever

Description

A stateless read-only contract that does exhaustive lookups against the registry coordinator for fetching operator metadata. This bundles stored procedure logic to avoid exhaustive RPC calls made to view functions by offchain EigenDA services.

Access Mgmt

N/A

Offchain Usage

TODO

EigenDARegistryCoordinator

Description

This contract orchestrates operator lifecycle across EigenDA's stake, BLS key, index, and socket registries - handling:

• registration, deregistration
• churning
• stake-updates
• quorum creation/config
• historical quorum-bitmap tracking

Access Mgmt

• Pauser role that can halt operator state updates
• Ownable role that can add new quorums, operator set params, & ejector params / role changes
• Ejector role that can invoke an ejection function to forcibly deregister an operator

Offchain Usage

TODO

EigenDAEjectionsManager

Description Coordinates the lifecycle of ejecting non-responsive operators from EigenDA. It allows an Ejector role to queue and complete ejections. Each queued ejection has a corresponding bond attached by the Ejector where a targeted operator can cancel the ejection by providing a signature before it becomes "confirmable" after a number of DelayBlocks.

Access Mgmt

• Ownable role that can change public parameters (i.e, DelayBlocks, CooldownBlocks)
• Ejector role that can invoke an ejection function to forcibly deregister an operator

Offchain Usage

TODO

CertVerifierRouter

Description

See here.

Access Mgmt

• Ownable role that can add new EigenDACertVerifier entries at new activation block number

Offchain Usage

This dynamic naming pattern requires off-chain management of canonical contract keys, allowing clients and services to retrieve on-chain system context from a single directory contract reference rather than requiring every contract address to be hard-coded or passed through environment configuration.

Governance Roles

There are four key governance roles in the EigenDA contracts seen across network environments (i.e, mainnet, hoodi-testnet, hoodi-preprod, sepolia-testnet):

• ERC1967 ProxyAdmin that can upgrade implementation contracts
• Owner that can perform sensitive stateful operations across protocol contracts
• Pauser that can halt stateful updates on the ServiceManager and RegistryCoordinator contracts. This role is managed by the immutable PauserRegistry contract
• Ejector that can initialize and complete ejection requests via the EjectionsManager contract