Eigenlayer

Skill is based on EigenLayer contracts (eigenlayer-contracts) as of 2026-02-24, generated from sources/eigenlayer/docs/.

EigenLayer enables restaking of LSTs, native ETH, and ERC-20s on Ethereum; stakers delegate to operators who run AVSs (Actively Validated Services). AVSs use operator sets and allocations for slashable stake and rewards; optional TaskMailbox and multichain support task-based execution and consumption of L1 stake on destination chains.

Core References

Features

Best Practices

Generation Info

• Source: sources/eigenlayer
• Git SHA: 264f6624906ec536c2cd8c8c6fe034f394762485
• Generated: 2026-02-24

Slashing and AVS Design

Slashing in EigenLayer should be on-chain-checkable and objectively attributable. AVSs should define tasks with finite duration and use AllocationManager operator sets and slasher configuration correctly.

Objectively attributable behavior

• Do slash for: double-signing, invalid state roots, proof-of-custody violations, invalid cross-chain attestations—anything that can be verified on-chain with a proof.
• Avoid slashing for: inactivity, “subjective” misbehavior, or conditions that are not verifiable on-chain. Operators and other AVSs may avoid or penalize AVSs that use subjective slashing.

Task duration

• Each task (if using a task-based model) should have a bounded duration so operator stake is not “at stake” indefinitely. Recommend aligning max task duration with operator expectations (e.g. MAX_TASK_SLA = DEALLOCATION_DELAY/2 in TaskMailbox so deallocation cannot be used to escape slashing for in-flight tasks).

Operator sets and slasher

• AVS creates operator sets with createOperatorSets (or CreateSetParamsV2 with slasher). One slasher per operator set (v1.9.0+); slashOperator must be called with the slasher address that is registered for that set.
• Only the AVS (or its PermissionController appointee) should be able to call slashOperator for that AVS’s sets; slasher contract should enforce that only valid proofs lead to slashing.

Single point of interaction

• Prefer a single AVS contract (e.g. ServiceManager) that talks to AllocationManager, RewardsCoordinator, and TaskMailbox. Multiple contracts that each call core make operator and staker flows harder to reason about and audit.

Usage for agents

• When implementing AVS slashing: require a proof (e.g. from a dispute resolution or verification contract) that is checked on-chain before calling AllocationManager.slashOperator.
• When designing tasks: set SLA and max duration so that (1) operators have enough time to complete, (2) stake is not locked indefinitely, (3) deallocation cannot be used to avoid slashing for that task.
• Document slashing conditions clearly so operators and restakers can assess risk.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/experimental/AVS-Guide.md
• sources/eigenlayer/docs/core/AllocationManager.md
• ELIP-002

-->

Withdrawal Flows

All withdrawals go through DelegationManager: queue first, then after MIN_WITHDRAWAL_DELAY_BLOCKS complete as shares or as tokens. Never withdraw directly from StrategyManager or EigenPodManager.

Queue

• queueWithdrawals(Withdrawal[]): Each withdrawal specifies (strategies[], shares[], withdrawer). Staker’s deposit shares and operator shares are reduced; withdrawal is stored with completion block.
• undelegate(staker) queues a full withdrawal of all staker’s shares (same delay).

Complete as shares

• Use when the goal is to redelegate to another operator: complete queued withdrawal “as shares” so shares are re-credited to the staker; then call delegateTo(newOperator, ...).
• completeQueuedWithdrawals(..., receiveAsTokens = false) with appropriate params.

Complete as tokens

• Use when the user wants to exit to ERC20 or ETH. Provide the list of (strategy, token/recipient) for each withdrawal; StrategyManager/EigenPodManager will transfer tokens/ETH to the specified recipient.
• For beacon chain ETH: ensure the staker’s EigenPod has enough ETH to cover the withdrawal (e.g. partial withdrawals or validator exits already processed and checkpointed). If not, completion may revert or underflow.
• completeQueuedWithdrawals(..., receiveAsTokens = true, tokensToWithdraw[], ...).

EigenPod and validator exits

• Full exit of native ETH: staker must (1) exit validators on beacon chain, (2) submit proofs in EigenPod so balance is credited, (3) then complete the queued withdrawal as tokens.
• Partial withdrawals and consensus/execution rewards: use verifyCheckpointProofs (and related) so pod balance and shares update; then user can compound (leave in strategy) or queue withdrawal and complete as tokens.

Usage for agents

• Always use DelegationManager for queue and complete; never call strategy or pod withdraw functions directly for “protocol” withdrawals.
• Before complete-as-tokens for beaconChainETHStrategy, check EigenPod balance and that checkpoint proofs are done so ETH is available.
• Respect MIN_WITHDRAWAL_DELAY_BLOCKS when showing “withdrawable at” time.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/README.md (Common User Flows)
• sources/eigenlayer/docs/core/DelegationManager.md
• sources/eigenlayer/docs/core/EigenPodManager.md

-->

AllocationManager

The AllocationManager is the AVS-facing core contract: AVS metadata, operator sets, operator registration/deregistration, allocations (slashable stake commitments), and slashing. An AVS is the address of a contract implementing the AVS logic (e.g. ServiceManagerBase); that address is the AVS “account” for PermissionController.

Contract shape

• Uses split contract pattern: main contract (state-changing) + view contract for size limits; same external interface.
• Key delays: ALLOCATION_CONFIGURATION_DELAY (allocations take effect), DEALLOCATION_DELAY (deallocations), SLASHER_CONFIGURATION_DELAY.

AVS metadata

• updateAVSMetadataURI(metadataURI)

AVS registers/updates its metadata URI. Required before creating operator sets.

Operator sets

• createOperatorSets(avs, CreateSetParams[]) (or CreateSetParamsV2[] with slasher).

AVS creates one or more operator sets; each set has strategies and optional slasher. From v1.9.0, one slasher per operator set stored in AllocationManager.

• addStrategiesToOperatorSet / removeStrategiesFromOperatorSet

AVS updates which strategies (and weights) are in an operator set.

• registerForOperatorSets(operator, operatorSetKeys, salt, expiry, signature)

Operator registers for the given sets (signature may be required).

• deregisterFromOperatorSets(operator, operatorSetKeys)

Operator (or AVS for some flows) deregisters; subject to deallocation delay for in-flight stake.

Allocations and slashing

• modifyAllocations(operatorSetKeys, newAllocations)

Operator allocates a fraction of their delegated stake per strategy to be slashable by the given operator sets. Takes effect after allocation configuration delay.

• slashOperator(operatorSetKey, operator, slasher, slashAmounts)

AVS (via slasher) slashes an operator in an operator set; slash amounts per strategy. DelegationManager and StrategyManager/EigenPodManager apply share burns and scaling.

PermissionController

• Operators: modifyAllocations, registerForOperatorSets, deregisterFromOperatorSets, setAllocationDelay (and DelegationManager/RewardsCoordinator methods).
• AVSs: slashOperator, createOperatorSets, add/remove strategies, updateAVSMetadataURI, setAVSRegistrar, etc.
• Caller must be the account or an admin/appointee for that account.

Usage for agents

• AVS: register metadata → create operator sets (with strategies/slasher) → receive operator registrations → operators allocate → on misbehavior call slashOperator.
• Operator: registerAsOperator (DelegationManager) → registerForOperatorSets → modifyAllocations to put stake at risk for AVSs.
• Query view contract for operator set list, allocations, and slashing state (same interface as main contract).

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/AllocationManager.md
• ELIP-002

-->

DelegationManager

The DelegationManager sits between StrategyManager/EigenPodManager and operators. It handles: (1) operator registration and metadata, (2) staker delegation/undelegation, (3) withdrawal queue and completion (shares or tokens), (4) slashing accounting (deposit scaling factors, withdrawable shares).

Key Parameters

• MIN_WITHDRAWAL_DELAY_BLOCKS: mainnet 100800 (~14 days), testnet 50.
• beaconChainETHStrategy: pseudo-address 0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0 (not a real contract).

Becoming an Operator

function registerAsOperator(
    address initDelegationApprover,
    uint32 allocationDelay,
    string calldata metadataURI
) external;

• Caller becomes operator and is permanently self-delegated.
• initDelegationApprover: if set, stakers need this address’s signature to delegate to this operator.
• allocationDelay: blocks before new allocations take effect (used by AllocationManager).

function modifyOperatorDetails(address operator, address newDelegationApprover) external;
function updateOperatorMetadataURI(address operator, string calldata metadataURI) external;

• PermissionController: operator or their admin/appointee can call.

Delegation and Withdrawals

• delegateTo(operator, signature): Staker delegates existing deposit shares to operator. Signature required if operator has a delegation approver.
• undelegate(staker): Staker undelegates; triggers queuing a full withdrawal of their shares (withdrawal delay applies).
• queueWithdrawals(Withdrawal[])

Queues withdrawals: specify (strategies, shares). Shares are decremented from staker and operator; after delay, staker can complete.

• completeQueuedWithdrawals(withdrawals, tokensToWithdraw, middlewareTimesIndexes, receiveAsTokens)

Completes queued withdrawals: either re-credit shares to staker or withdraw as tokens. For tokens, provide strategy list and recipient; StrategyManager/EigenPodManager perform actual token/ETH transfer.

Withdrawable shares

• getWithdrawableShares(staker, strategies) returns withdrawable share amounts (deposit shares × deposit scaling factor × slashing factors). Use this to know how much can be withdrawn or delegated.
• Operator shares in DelegationManager are the sum of delegated stakers’ withdrawable shares per strategy.

Slashing

When AllocationManager slashes an operator, DelegationManager updates slashing state; stakers under that operator see reduced withdrawable shares via deposit scaling factor. No iteration over stakers—slashing is applied asynchronously through these factors.

Usage for agents

• Register operator once; then use AllocationManager for AVS operator sets and allocations.
• Staker flow: deposit (StrategyManager/EigenPodManager) → delegateTo → (optional) queueWithdrawals → after delay completeQueuedWithdrawals.
• Check withdrawable amounts with getWithdrawableShares before queueing withdrawals or showing UI.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/DelegationManager.md

-->

EigenPodManager and Native ETH Restaking

The EigenPodManager manages the virtual beacon chain ETH strategy (address 0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0). It creates EigenPods and forwards balance/share updates to the DelegationManager.

Key Parameters

• beaconChainETHStrategy: 0xbeaC0eeEeeeeEEeEeEEEEeeEEeEeeeEeeEEBEaC0 (pseudo-address, not a contract).
• ethPOS: Beacon deposit contract.
• EigenPods deployed via Create2 + beacon proxy (one per staker).

Depositing (Native ETH)

1. createPod() Deploys an EigenPod for the caller (Pod Owner). One pod per address. Reverts if pod already exists.

2. stake(pubkey, signature, depositDataRoot) Stakes a new validator on the caller’s pod (creates pod if needed). Sends 32 ETH to ethPOS; validator’s withdrawal credentials should point to the pod (0x01 or 0x02).

3. In EigenPod: verifyWithdrawalCredentials proves validator’s withdrawal credentials point to the pod; verifyCheckpointProofs (and related) complete checkpoints so the Pod Owner receives deposit shares for beacon balance and pod ETH balance.

Balance increases (e.g. rewards, partial withdrawals) → more deposit shares. Balance decreases (slashing, inactivity) → no reduction in deposit shares; instead beaconChainSlashingFactor is reduced, so withdrawable shares drop (see DelegationManager / shares accounting).

Withdrawal Processing

• Withdrawals are always via DelegationManager: queue withdrawal for beaconChainETHStrategy shares, then complete as shares or as tokens.
• Completing as tokens may require the pod to have sufficient ETH (e.g. from partial withdrawals or exits). Validator exits: user must process exits and proof in EigenPod so balance is available; then complete the queued withdrawal as tokens.

Usage for agents

• Native restaking flow: EigenPodManager.createPod() → EigenPodManager.stake(...) → set validator withdrawal credentials to pod → EigenPod.verifyWithdrawalCredentials → later EigenPod.verifyCheckpointProofs to get/update shares.
• Withdraw: use DelegationManager queueWithdrawals with beaconChainETHStrategy, then completeQueuedWithdrawals. For token payout, ensure pod has ETH (checkpoints, exits) before completing.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/EigenPodManager.md

-->

EigenPod

An EigenPod is a per-staker contract (Pod Owner) created via EigenPodManager. It can serve as withdrawal credentials and/or fee recipient for one or more beacon chain validators. It verifies beacon state proofs and runs checkpoints to update the Pod Owner’s deposit shares in the beacon chain ETH strategy.

Roles

• Pod Owner: Staker who owns the pod; receives deposit shares; can set Proof Submitter.
• Proof Submitter: Optional hot wallet allowed to call proof/checkpoint methods (e.g. verifyWithdrawalCredentials, verifyCheckpointProofs).

Restaking flow

1. Point validator’s withdrawal credentials (and optionally fee recipient) to the EigenPod address. 2. verifyWithdrawalCredentials(validatorIndex, validatorSignature, proofs) Proves to the pod that the validator’s withdrawal credentials point to this pod; validator enters “active validator set.” 3. verifyCheckpointProofs(proofs) Submits one proof per active validator; when all are submitted, the checkpoint completes: pod balance and beacon balance deltas are applied, Pod Owner’s deposit shares in EigenPodManager are updated (rewards/partial withdrawals increase shares; exits can free balance for withdrawal).

Checkpoint structure (conceptual)

• One checkpoint at a time per pod.
• Tracks: beacon block root, proofs remaining, pod balance (Gwei), balance deltas, previous beacon balance.
• Completing a checkpoint: proofs for every active validator; then shares and (if applicable) beaconChainSlashingFactor are updated.

Staleness and exits

• Staleness proofs can remove validators that have exited or dropped balance without full proof set.
• For full exit: user processes validator exit and proofs so ETH lands in the pod; then they can complete a DelegationManager withdrawal “as tokens.”

Usage for agents

• After staking (EigenPodManager.stake), validators must have withdrawal credentials (and optionally fee recipient) set to the pod.
• Call verifyWithdrawalCredentials once per validator to add them to the active set.
• Call verifyCheckpointProofs (and related) to complete checkpoints and credit shares for new balance; repeat as new rewards/withdrawals occur.
• Use Proof Submitter for automation; Pod Owner keeps custody.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/EigenPod.md

-->

EigenLayer Core Overview

EigenLayer is a protocol on Ethereum that introduces restaking: stakers deposit LSTs, native ETH, or ERC-20s; delegate to operators; operators run AVSs (Actively Validated Services) and can be slashed. Core contracts are upgradeable (transparent proxy) and work together for deposits, delegation, withdrawals, and slashing.

System Components

Roles

• Staker: Deposits via StrategyManager (ERC20s) or EigenPodManager (native ETH); withdraws only via DelegationManager; may delegate to an operator.
• Operator: Registers in DelegationManager (self-delegation); opts into AVSs via AllocationManager operator sets; receives delegated stake; can be slashed by AVSs.

Key Flows (for agents)

1. Deposit: StrategyManager depositIntoStrategy(strategy, token, amount) or EigenPodManager createPod() + stake/verifyWithdrawalCredentials + checkpoint. 2. Delegate: DelegationManager delegateTo(operator, signature). 3. Withdraw: DelegationManager queueWithdrawals then after delay completeQueuedWithdrawals (as shares or as tokens). 4. AVS: AllocationManager for operator sets, allocations, and slashing; RewardsCoordinator for rewards; TaskMailbox for task-based execution (see features).

Contract Locations

• Core: src/contracts/core/ (StrategyManager, DelegationManager, AllocationManager, AVSDirectory, RewardsCoordinator, ReleaseManager).
• Pods: src/contracts/pods/ (EigenPodManager, EigenPod).
• Strategies: src/contracts/strategies/ (StrategyBase, StrategyFactory, EigenStrategy).
• Permissions: src/contracts/permissions/ (PermissionController, KeyRegistrar, PauserRegistry).

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/README.md

-->

RewardsCoordinator

The RewardsCoordinator accepts ERC20 rewards from AVSs, keyed to operators (and their stakers) registered in the AllocationManager. Rewards are submitted with a time range; off-chain a rewards updater computes distributions and posts a DistributionRoot (merkle root); stakers and operators (or their claimers) claim with merkle proofs.

Reward types

• v1 (RewardsSubmission): AVS submits total amount and strategy weights; updater distributes by stake weight and default operator split.
• v2 (OperatorDirectedRewardsSubmission): Per-operator amounts and custom AVS logic; operators can set AVS/operator set/PI splits (basis points).

Flow

1. AVS: createAVSRewardsSubmission or createOperatorDirectedAVSRewardsSubmission (token, time range, amounts/weights). 2. Off-chain: rewards updater builds merkle tree of cumulative earnings per earner per token; posts root via submitDistributionRoot (or equivalent). 3. After activation delay, earners (or claimerFor) call processClaim(claim, recipient) with merkle proof; token is transferred to recipient.

Important state

• distributionRoots: historic merkle roots (cumulative earnings).
• claimerFor[earner]: address that may call processClaim on behalf of earner.
• cumulativeClaimed[earner][token]: already claimed amount; claim pays (cumulativeInTree - cumulativeClaimed).
• defaultOperatorSplitBips, _operatorAVSSplitBips, _operatorPISplitBips, _operatorSetSplitBips: control operator vs staker split (used off-chain or in contract logic).

Usage for agents

• AVS: create rewards submission for a time range and token; ensure operators are registered in AllocationManager for that period.
• Earner: set claimerFor if another address should claim; call processClaim with valid merkle proof and desired recipient.
• Use nonstandard ERC20s with caution (rebasing, fee-on-transfer, reentrancy).

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/RewardsCoordinator.md
• ELIP-001 operator-directed rewards

-->

Shares Accounting

EigenLayer distinguishes deposit shares, withdrawable shares, and operator shares. Slashing is applied via scaling factors rather than iterating over stakers.

Terminology

• Deposit shares: Held in StrategyManager / EigenPodManager; ~1:1 with deposited assets per strategy. Managed at deposit/withdrawal queue.
• Withdrawable shares: Deposit shares × deposit scaling factor × (beacon chain slashing factor) × operator magnitude. Not stored; computed in DelegationManager.getWithdrawableShares(staker, strategies).
• Operator shares: Sum of all stakers’ withdrawable shares delegated to that operator, per strategy. Stored in DelegationManager.

Stored Variables (per strategy)

• Staker: s_n deposit shares; k_n deposit scaling factor; l_n beacon chain slashing factor (EigenPod only).
• Operator: m_n magnitude; op_n operator shares (= sum of delegated withdrawable shares).

Key formulas (conceptual)

• Withdrawable: a_n = s_n * k_n * l_n * m_n.
• On deposit: scaling factor is updated so the new deposit adds the right amount of withdrawable shares.
• On slashing: operator’s magnitude/slashing state changes; stakers’ withdrawable shares drop via k_n / l_n / m_n; deposit shares s_n unchanged until withdrawal.

When to use

• Deposits: StrategyManager/EigenPodManager increase deposit shares and notify DelegationManager; DelegationManager updates scaling so new shares count as withdrawable.
• Withdrawals: Queue reduces deposit shares; completion pays out based on withdrawable value (shares or tokens).
• Slashing: AllocationManager triggers slashing; DelegationManager updates factors so withdrawable shares decrease; StrategyManager/EigenPodManager can burn slashed shares (tokens to burn address).

Usage for agents

• Use DelegationManager.getWithdrawableShares(staker, strategies) for “how much can be withdrawn/delegated” and for UI/analytics.
• Do not assume 1:1 deposit shares to tokens after slashing; use withdrawable shares and strategy share-to-asset conversion for accurate amounts.
• Beacon chain ETH: EigenPodManager uses beaconChainSlashingFactor for validator slashing/inactivity; same scaling idea applies.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/accounting/SharesAccounting.md
• ELIP-002 Slashing via Unique Stake and Operator Sets

-->

StrategyManager and Strategies

The StrategyManager handles deposit share accounting for stakers depositing into whitelisted strategies. It does not handle withdrawals directly—withdrawals are queued and completed through the DelegationManager.

Key Parameters

• MAX_TOTAL_SHARES = 1e38 - 1 per strategy.
• MAX_STAKER_STRATEGY_LIST_LENGTH = 32 strategies per staker.
• Slashed shares are sent to DEFAULT_BURN_ADDRESS.

Depositing

// Direct deposit: caller gets shares
function depositIntoStrategy(
    IStrategy strategy,
    IERC20 token,
    uint256 amount
) external returns (uint256 depositShares);

// Deposit on behalf of another staker (staker must sign)
function depositIntoStrategyWithSignature(
    IStrategy strategy,
    IERC20 token,
    uint256 amount,
    address staker,
    uint256 expiry,
    bytes memory signature
) external returns (uint256 depositShares);

• Requires strategy whitelisted and token matching strategy’s underlying token.
• Caller must approve StrategyManager for token.
• After deposit, DelegationManager updates staker’s delegated shares (if delegated).

Strategies

• StrategyFactory.deployNewStrategy(token)

Deploys a StrategyBase (beacon proxy) for an ERC20; strategy is auto-whitelisted. One strategy per token; EIGEN/bEIGEN and some LSTs are blacklisted (use EigenStrategy or existing StrategyBaseTVLLimits).

• StrategyBase: Standard ERC20 strategy; shares ≈ 1:1 with tokens (strategy defines exchange rate).
• EigenStrategy: Used only for EIGEN/bEIGEN.
• StrategyBaseTVLLimits: Legacy LST strategies (transparent proxy); same behavior as StrategyBase for deposits/withdrawals.

Withdrawal Flow (via DelegationManager)

1. Staker calls DelegationManager.queueWithdrawals (specifies strategies and share amounts). 2. StrategyManager/DelegationManager reduce staker’s deposit shares and operator shares. 3. After withdrawal delay, staker calls DelegationManager.completeQueuedWithdrawals either:

• as shares (re-credit to staker, e.g. to redelegate), or
• as tokens (StrategyManager withdraws from strategy and sends tokens to recipient).

Burning slashed shares

When an AVS slashes an operator, AllocationManager instructs DelegationManager to slash; StrategyManager’s slashShares is used to burn slashed deposit shares (tokens sent to burn address).

Usage for agents

• To support a new ERC20: call StrategyFactory.deployNewStrategy(token) (if not blacklisted).
• Deposit: StrategyManager.depositIntoStrategy(strategy, token, amount) after approval.
• Withdraw: use DelegationManager queueWithdrawals and completeQueuedWithdrawals; do not withdraw directly from StrategyManager.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/core/StrategyManager.md

-->

Multichain

The EigenLayer multichain design lets destination chains (e.g. Base) consume L1 stake: operator tables are derived from AllocationManager/KeyRegistrar on the source chain (e.g. Ethereum mainnet), signed by a generator, and transported to destination chains. CertificateVerifiers on destination chains verify task/result certificates against these tables.

Source chain (e.g. mainnet)

• CrossChainRegistry: AVSs makeGenerationReservation (or equivalent) for operator sets they want transported. They deploy an OperatorTableCalculator per set (and key type) that reads EigenLayer core (DelegationManager, AllocationManager, KeyRegistrar) and computes operator table bytes.
• Generator (off-chain): At a cadence, reads active reservations and calculator outputs, builds globalTableRoot, signs it.
• Transporter (permissionless): Carries signed root and table updates to destination chains.

Destination chain

• OperatorTableUpdater:
• confirmGlobalTableRoot: Accepts signed root from generator (certificate).
• updateOperatorTable: Updates an operator table via merkle proof against the confirmed root.
• CertificateVerifier (BN254 and ECDSA): Store/update operator table; verify signatures for task results. TaskMailbox (and AVSs) use these to verify operator set consensus on destination chain.

KeyRegistrar

• AVS must set KeyType in KeyRegistrar on source chain even if keys are stored elsewhere, so operator table generation knows which key type to use for that AVS/set.

Usage for agents

• AVS on destination: register for generation/transport on source (CrossChainRegistry + OperatorTableCalculator); ensure KeyRegistrar and operator set are correct.
• Submitting task results on destination: use TaskMailbox (or AVS contract) with the appropriate CertificateVerifier; operator table must be up to date (transporter updates via OperatorTableUpdater).
• Read ELIP-008 for full protocol and roles (Generator, Transporter).

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/multichain/README.md
• sources/eigenlayer/docs/multichain/source/CrossChainRegistry.md
• sources/eigenlayer/docs/multichain/destination/OperatorTableUpdater.md
• sources/eigenlayer/docs/multichain/destination/CertificateVerifier.md
• ELIP-008

-->

PermissionController and KeyRegistrar

PermissionController lets AVSs and operators (not stakers) delegate calling rights to other addresses. KeyRegistrar lets operators register keys (e.g. for BLS/ECDSA) used by AVSs and multichain.

PermissionController roles

• Account: The address that “holds” protocol state (e.g. operator address in DelegationManager, AVS address in AllocationManager). Only accounts that are AVSs or operators can use PermissionController.
• Admins: Can perform any PermissionController-gated action for the account (e.g. modifyOperatorDetails, modifyAllocations, slashOperator). Add via addPendingAdmin; pending accepts with acceptAdmin. If any admin is set, the account must explicitly add itself as admin to remain able to act.
• Appointees: Granted permission for specific (target contract, selector) pairs. Used for limited delegation (e.g. only setClaimerFor, or only registerForOperatorSets).

Operator-enabled methods (examples)

• DelegationManager: modifyOperatorDetails, updateOperatorMetadataURI, undelegate.
• AllocationManager: modifyAllocations, registerForOperatorSets, deregisterFromOperatorSets, setAllocationDelay.
• RewardsCoordinator: setClaimerFor, setOperatorAVSSplit, setOperatorPISplit.

AVS-enabled methods (examples)

• AllocationManager: slashOperator, deregisterFromOperatorSets, setAVSRegistrar, updateAVSMetadataURI, createOperatorSets, add/remove strategies.
• RewardsCoordinator: createOperatorDirectedAVSRewardsSubmission, setClaimerFor.

KeyRegistrar

• Operators (and AVSs) register key type and key data (e.g. BLS pubkey, ECDSA address) for use by AVSs and by multichain (OperatorTableCalculator, certificate verification).
• Required for multichain: AVS must set KeyType in KeyRegistrar even if keys are stored elsewhere, so generation/transport can resolve operator tables.

Usage for agents

• Operator key rotation: add new admin (or appointee) then use it for modifyOperatorDetails / modifyAllocations; optionally remove old key.
• AVS: set appointee for slashOperator only, or admin for full AVS control.
• Multichain AVS: ensure KeyRegistrar has correct key type for the AVS/operator set.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/permissions/PermissionController.md
• sources/eigenlayer/docs/permissions/KeyRegistrar.md

-->

TaskMailbox

TaskMailbox is a core contract for task-based AVSs: tasks are created with a fee and executor operator set; operators execute off-chain and submit results; the contract verifies consensus (certificates) and updates task state.

Immutable config

• BN254_CERTIFICATE_VERIFIER, ECDSA_CERTIFICATE_VERIFIER: used to verify submitted results.
• MAX_TASK_SLA: max task duration (e.g. DEALLOCATION_DELAY/2) so operators cannot deallocate before task resolution and avoid slashing.

Task lifecycle

1. CREATED: createTask(taskParams) returns taskHash. Params: refund collector, executor operator set, payload, SLA. Certificate staleness check: block.timestamp + taskSLA <= operatorTableReferenceTimestamp + maxStaleness (if maxStaleness set). 2. VERIFIED: Operators submit result; contract verifies against operator set and certificate; task marked verified and fees distributed. 3. EXPIRED: If SLA passes without verified result, task can be marked expired (refund logic as per contract).

Executor operator sets

• Each task specifies an executor operator set (key). Consensus thresholds and task SLA are configured per operator set.
• Fee split (protocol vs AVS) is configurable (basis points).

Result submission and verification

• Submitter provides result payload and certificate (BN254 or ECDSA). Contract uses OperatorTableUpdater / certificate verifiers to validate that the signers match the operator set and meet stake threshold.
• getTaskInfo(taskHash), getTaskStatus(taskHash) for current state.

Task hooks and AVS integration

• AVSs can plug in hooks (if supported) for task creation or result handling; see contract and AVS docs for hook signatures.

Usage for agents

• Create task with correct operator set key and SLA ≤ MAX_TASK_SLA; ensure operator table is fresh (staleness check).
• Submit results with valid certificate for the task’s operator set and chain (multichain: use correct destination and verifier).
• Query task status before refund or completion logic.

<!-- Source references:

• https://github.com/Layr-Labs/eigenlayer-contracts
• sources/eigenlayer/docs/avs/task/TaskMailbox.md
• Hourglass framework, AllocationManager, KeyRegistrar, CertificateVerifier

-->