DOCSEARCHbyAlgolia
Submit Docs

EigenLayer Contracts

repository·main·Indexed 20 days ago

https://github.com/layr-labs/eigenlayer-contracts

Contracts and tools for the EigenLayer protocol, focusing on restaking primitives and the multichain protocol. Includes core system components such as EigenPodManager for native ETH restaking, StrategyManager for ERC20/LST restaking, DelegationManager, RewardsCoordinator, and AllocationManager. The multichain protocol enables the consumption of L1 stake on destination chains (Ethereum Mainnet and Base) via CrossChainRegistry, OperatorTableCalculator, and OperatorTableUpdater.

Tokens
110.7K
Snippets
216
Records
351
Agent score
69%

What's inside eigenlayer-contracts

  1. Overview of CrossChainRegistry

    main

    The CrossChainRegistry is a singleton contract (deployed via a Transparent Proxy) that manages the registration and deregistration of operatorSets for the multichain protocol.

    Its primary responsibilities include:

    • Managing operatorSet registrations to enable cross-chain operations.
    • Providing read-only functions to calculate operator tables.
    • Enabling the Generator to create a GlobalTableRoot and the Transporter to move operator tables to destination chains.

    Note: Operator tables are transported to all whitelisted destination chains, even if the specific operatorSet is not consumed on a particular destination chain.

  2. Overview of TaskMailbox

    main

    The TaskMailbox is a core infrastructure contract designed for task-based AVS (Autonomous Verifiable Service) execution. It provides a standardized mechanism for users or applications to create tasks, for operators to compete for and execute those tasks, and for verified results to be submitted on-chain.

    Key responsibilities include:

    • Task Lifecycle Management: Handling creation, expiration, and verification states.
    • Executor Operator Sets: Managing which operators are eligible to execute specific tasks.
    • Result Submission and Verification: Ensuring submitted results meet consensus requirements.
    • Fee Management: Distributing fees between the protocol and the AVS.
    • AVS Integration: Providing hooks for AVS-specific validation and handling.

  3. Overview of EigenLayer and Restaking

    main

    EigenLayer is an Ethereum-based protocol that introduces Restaking. This primitive allows application and service builders to make verifiable commitments to users by leveraging Ethereum's cryptoeconomic security.

    Through Restaking, the protocol coordinates three main roles:

    • Restakers: Provide staked assets to act as security.
    • Operators: Execute tasks and maintain services.
    • Autonomous Verifiable Services (AVSs): Utilize the security provided by restaked assets.

    The protocol supports permissionless security using various assets, including EIGEN, Native ETH, LSTs (Liquid Staking Tokens), and ERC-20s. Security is enforced through penalty and reward commitments, such as slashing.

  4. Overview of the EigenLayer Multichain Protocol

    main

    The EigenLayer multichain protocol enables the consumption of EigenLayer L1 stake on supported destination chains.

    Supported Chains:

    • Source Chain: Ethereum Mainnet
    • Destination Chains: Ethereum Mainnet and Base

    High-Level Protocol Flow:

    1. AVS Registration: An AVS registers for generation/transport via CrossChainRegistry.makeGenerationReservation and deploys an OperatorTableCalculator.
    2. Global Root Generation: An off-chain Generator process retrieves active generations from the CrossChainRegistry and signs a globalTableRoot of all operator table commitments.
    3. Root Transport: A Transporter carries a Certificate (validating the Generator signature) and the globalTableRoot to all destination chains.
    4. Table Updates: The Transporter updates operator tables on destination chains using merkle proofs against the globalTableRoot via the OperatorTableUpdater.

  5. Review EigenLayer deployment environments and capabilities

    main

    The EigenLayer protocol is deployed across multiple environments with varying levels of support for core features. Use this reference to determine if an environment supports the features required for your integration.

    Deployment Matrix

    EnvironmentVersionCore ProtocolNative RestakingMultichain Support
    Mainnet Ethereumv1.13.0YesYesYes (source & destination)
    Basev1.9.0NoNoYes (destination)
    Testnet Sepoliav1.12.1YesNoYes (source & destination)
    Testnet Hoodiv1.11.0YesYesNo
    Testnet Base Sepoliav1.9.0NoNoYes (destination)

  6. Understand the EigenLayer Core System Components

    main

    The EigenLayer core contracts enable restaking of liquid staking tokens (LSTs), beacon chain ETH, and permissionlessly deployed ERC20 Strategies to secure Actively Validated Services (AVSs). The system is composed of several key management contracts:

    • EigenPodManager: Manages EigenPods for native ETH restaking. EigenPods serve as fee recipients or withdrawal credentials for validators.
    • StrategyManager: The entry/exit point for ERC20/LST restaking. It manages deposits and interactions between LST users and the DelegationManager.
    • DelegationManager: Manages the delegation and undelegation of stakers to operators. It tracks delegated shares and manages withdrawals on behalf of stakers.
    • RewardsCoordinator: The entry point for submitting and claiming ERC20 rewards from AVSs.
    • AllocationManager: Replaces the deprecated AVSDirectory. It manages AVS operator sets, operator registrations, and slashable security commitments.
    • PermissionController: Allows AVSs and operators to delegate specific core contract function permissions to other addresses.
    • AVSDirectory (Deprecated): Formerly handled AVS/Operator registrations; now superseded by AllocationManager.

  7. AVS Interaction Capabilities with EigenLayer

    main

    Current AVS developers can use existing APIs to perform the following operations:

    • Operator Opt-in: Enable operators to join the AVS.
    • Operator Opt-out: Enable operators to withdraw stake from the AVS.
    • Commitment Updates: Allow operators to continuously update their commitments to middlewares.
    • Slashing (Freezing): Enable the AVS to freeze operators for slashing purposes. Note that unfreezing actions are handled by a veto committee.

    Warning: The Slasher.sol contract is under active development. It is recommended to write slashing logic without integrating directly with the Slasher contract at this time.

  8. What is the ProtocolRegistry?

    main

    The ProtocolRegistry is the canonical catalog of EigenLayer protocol deployments. It serves as a central registry on all EigenLayer source and destination chains to:

    • Map human-readable deployment names to contract addresses.
    • Track per-contract configuration flags (e.g., whether a contract is pausable or deprecated).
    • Emit semantic-version updates whenever a new protocol shipment occurs.
    • Provide a mechanism to trigger emergency pausing across all compatible deployments via pauseAll().

  9. What is an inflation attack and how is it mitigated?

    main

    An inflation attack occurs when an attacker manipulates the exchange rate of a newly created StrategyBase contract to make it so high that subsequent depositors receive 0 shares due to EVM division rounding. This allows the attacker (who holds the only existing shares) to steal the deposited funds.

    Mitigation: Virtual Shares

    To prevent this, StrategyBase uses a virtual shares mechanism. Every contract is initialized with a set amount of virtual shares and virtual tokens (defaulting to 1e3 of each).

    This mechanism ensures:

    1. The first depositor does not own 100% of the shares: Even a minimal deposit results in a tiny fraction of the total shares, preventing the attacker from controlling the entire pool.
    2. Economic Disincentive: If an attacker attempts to inflate the exchange rate using large amounts of capital, the virtual depositor causes the attacker to lose a portion of their own capital (dilution), making the attack unprofitable.
    3. Rounding Protection: The presence of virtual shares ensures the exchange rate is never high enough to force legitimate deposits to round down to 0 shares.

  10. Overview of CertificateVerifier contracts

    main

    The CertificateVerifier contracts provide on-chain verification for certificates generated by off-chain tasks. They rely on operatorSet tables (configured via OperatorTableUpdater) to validate signatures.

    There are two primary implementations based on the required signature scheme:

    • ECDSACertificateVerifier: Used for individual ECDSA signatures.
    • BN254CertificateVerifier: Used for aggregated BN254 (BLS) signatures.

    Key operational requirements:

    • Reference Timestamp: Every certificate must include a referenceTimestamp. This timestamp determines which version of the operatorSet table is used for verification.
    • Staleness Checks: Verifiers use a maxStalenessPeriod to prevent verifying certificates against outdated operator information.
    • Task Identification: Both verifiers use a msgHash parameter, which represents the hash of the completed task. Note: The msgHash itself is not signed; instead, operators sign a 'signable digest' derived from the msgHash and the referenceTimestamp via calculateCertificateDigest.

  11. What is EigenPodManager and how does it manage beacon chain ETH?

    main

    The EigenPodManager manages the "beacon chain ETH strategy", a virtual strategy where staker shares are backed by beacon chain validators or native ETH attributed to EigenPods.

    Unlike standard strategies backed by ERC20 tokens, the EigenPodManager handles balance updates from the beacon chain:

    • Balance Increases: (e.g., validator activity or ETH received in the EigenPod) result in an increase in the staker's deposit shares for the beacon chain ETH strategy.
    • Balance Decreases: (e.g., validator inactivity or slashing) do NOT decrease deposit shares. Instead, they decrease the staker's beacon chain slashing factor.

    The DelegationManager uses this slashing factor to determine how many deposit shares are actually withdrawable and how many can be delegated to an operator. You can query the number of withdrawable shares using DelegationManager.getWithdrawableShares(staker, strategies).

  12. Overview of OperatorTableUpdater

    main

    The OperatorTableUpdater is a singleton contract deployed on every destination chain. Its primary purpose is to manage the synchronization of operator tables across chains by:

    1. Maintaining a set of valid GlobalTableRoot values confirmed by a designated generator.
    2. Allowing individual operator tables to be updated using Merkle proofs against these confirmed global roots.

    The contract is curve-agnostic and routes updates to either the BN254CertificateVerifier or the ECDSACertificateVerifier based on the KeyType encoded in the operator table data.