PART ONE: Overview

Introduction

EigenLayer comprises smart contracts on the Ethereum platform, enabling assets staked on Ethereum to validate additional software modules. By participating in EigenLayer, stakers enhance the security of modules from consensus protocols to trusted execution environments and can earn additional rewards.

EigenLayer restaking is different system than liquid staking, It introduces restaking to extend cryptoeconomic security from Ethereum to additional applications on the network. Restakers in EigenLayer opt-in to secure multiple services simultaneously.

Liquid staking (Lido, Rocket pool) on the other hand is designed to solve the liquidity problem of staked assets. When assets are staked, they are typically locked and cannot be used elsewhere. Liquid staking provides a tokenized representation of these assets, making them liquid and usable within the DeFi ecosystem. However, these tokenized representations such as stETH or rETH then can be restake in EigenLayer.

In essence, by staking through EigenLayer, stakers can earn broader range of rewards and benefits, extending their influence and security guarantees across multiple services while maximizing their potential returns. It allows stakers to not only secure block production but also securing non-evm services that integrates with Ethereum ecosystem and used by dapps.

Users can stake to EigenLayer through two primary methods:

[if !supportLists]· [endif]Native Restaking: Ethereum stakers can restake their staked ETH natively by directing their withdrawal credentials to the EigenLayer contracts.

[if !supportLists]· [endif]LST Restaking: Holders of Liquid Staking Tokens (LSTs) such as stETH or rETH can restake by transferring these LSTs into the EigenLayer smart contracts.

EigenLayer, stakers receive rewards in multiple ways:

[if !supportLists]· [endif]Traditional Staking Rewards: When stakers restake their ETH or Liquid Staking Tokens (LSTs) on EigenLayer, they continue to receive the traditional staking rewards associated with Ethereum.

[if !supportLists]· [endif]Additional Rewards from Actively Validated Services (AVS): By opting into various services built on EigenLayer, stakers have the potential to earn additional rewards for the added security they provide to these services.

The exact amount and mechanism of these rewards may vary based on the specific service and the agreements or contracts associated with each service.

Actors:

Stakers:

Stakers provide security to the Ethereum network by staking ETH. In the EigenLayer context, they further extend their support to various AVS systems, ensuring their stability and functionality, while potentially earning additional rewards. Currently stakers who want to use native restaking have to run validator node. Stakers staking LSTs can use eigenlayer app to do that.

Operators:

Operators are nodes in EigenLayer that execute AVS realted software developed on top of EigenLayer. Upon registering with EigenLayer, they become eligible for delegation from stakers and can selectively opt into various services, each possibly enforcing its own set of slashing conditions to ensure adherence to service-specific rules and guidelines.

AVS:

AVS are the consumer of the pooled security and can issue slashing on based rules. From consensus protocols, which ensure unanimous decisions, to data layers that keep information accessible, AVS cater to diverse needs.

AVS has 2 components that are needed to integrate with eigenlayer:

[if !supportLists]a. [endif]Set of smart contracts to interact with eigenlayer smart contracts

[if !supportLists]b. [endif]AVS specific software needed to run on a node (Operator)

Slashing Mechanism:

The slashing mechanism in EigenLayer serves as a deterrent for validators who do not adhere to the protocol’s rules or act maliciously. Validators who violate these rules risk having a portion or all of their staked assets forfeited.

Why Slashing Matters

Deterrence: Slashing serves as a potent deterrent against malicious activities. The prospect of losing staked assets ensures validators think twice before acting against the protocol's interests.

Network Integrity: With slashing in place, the network remains secure, as validators are motivated to uphold its integrity and functionality.

Trustworthiness: For users and other participants, the slashing mechanism reinforces trust in the system. It assures them that validators are held to stringent standards, ensuring the protocol's reliability.

// Slasher.sol

[if !supportLists]n [endif]registration

/**

* @notice Gives the contractAddress permission to slash the funds of the caller.

* @dev Typically, this function must be called prior to registering for a middleware.

*/

function optIntoSlashing(address contractAddress) external onlyWhenNotPaused(PAUSED_OPT_INTO_SLASHING) {

require(delegation.isOperator(msg.sender), "Slasher.optIntoSlashing: msg.sender is not a registered operator");

_optIntoSlashing(msg.sender, contractAddress);

}

[if !supportLists]n [endif]Slashing

/**

* @notice Used for 'slashing' a certain operator.

* @param toBeFrozen The operator to be frozen.

* @dev Technically the operator is 'frozen' (hence the name of this function), and then subject to slashing pending a decision by a human-in-the-loop.

* @dev The operator must have previously given the caller (which should be a contract) the ability to slash them, through a call to optIntoSlashing.

*/

function freezeOperator(address toBeFrozen) external onlyWhenNotPaused(PAUSED_NEW_FREEZING) {

require(

canSlash(toBeFrozen, msg.sender),

"Slasher.freezeOperator: msg.sender does not have permission to slash this operator"

);

_freezeOperator(toBeFrozen, msg.sender);

}

Navigating the Slashing Landscape

While the threat of slashing looms, it's not an arbitrary penalty. The EigenLayer protocol defines clear criteria and conditions under which slashing occurs. Validators, fully aware of these conditions, can operate confidently, knowing that as long as they adhere to the rules, their assets remain safe.

However, if unfores­­een vulnerabilities can arise, EigenLayer acknowledges this and introduces governance layers that can veto slashing decisions. This protective measure ensures that validators aren't unduly penalized for unintended issues or vulnerabilities in new modules.

Slashing lifecycle

Staker. Solo staker eigenpod manager

Delegation to operator.

Operator registration in Eigenlayer

Opt into slashing through middleware’s ServiceManaer contract

freezeOperator

Slash or unfreeze (owner of the StrategyManager contract, who can also 'unfreeze' accounts.)

Restaking Points:

In EigenLayer, the measure of a staker's contribution to the shared security of the ecosystem is represented by "Restaked Points." These points are a time-integrated measure of staking participation.

The calculation for Restaked Points is as follows:

For each staker i and each token j:

Participation measure of staker i for token j=∫Sij​(t)dt

// add code snippet for variable that holds this information

Where:

• Sij​(t) represents the amount of token j held by staker i at time t, measured in nominal units of ETH.

• All tokens, such as natively staked ETH, stETH, and rETH, are treated equivalently, and the total participation measure is calculated in units of ETH-hours.

• For natively staked ETH, Sij​(t) is treated as a step function that transitions from 0 to 32 ETH at the validator's activation epoch and back to 0 at the validator's exit epoch.

To obtain the total participation measure for a staker i, the measures for each token held by that staker are summed up.

The restaked ratio then gives the ratio of a given staker i's participation measure to the aggregated participation measures across all stakers.

Risks and Mitigations

Slashing Penalties:Validators, while enjoying rewards, also face the risk of slashing if they deviate from the protocol's rules. This ensures they operate with integrity, but it also poses a risk to their staked assets.

Module Vulnerabilities:With numerous modules supported by EigenLayer, there's a potential risk of vulnerabilities in any module affecting the entire system. However, EigenLayer's governance mechanism and stringent validation processes act as safeguards against such threats.

Economic Fluctuations:The rewards and incentives are subject to economic conditions. Variations in asset values can influence the rewards and penalties, potentially impacting validators' and stakers' returns.

PART TWO: Smart Contracts

In this segment, we delve into the protocol's smart contracts. The protocol encompasses six distinct contract categories, besides libraries and interfaces. We'll explore each contract category, focusing on their primary operations.

1. Core Contracts :

[if !supportLists]a. [endif]DelegationManager.sol

[if !supportLists]· [endif]The DelegationManager is described as the primary delegation contract for EigenLayer. Its main functionalities include:

[if !supportLists]· [endif]Registering anyone as an operator in EigenLayer.

[if !supportLists]· [endif]Allowing new operators to provide a DelegationTerms-type contract to mediate interactions with stakers.

[if !supportLists]· [endif]Enabling stakers to delegate their stake to their chosen operator.

[if !supportLists]· [endif]Allowing stakers to undelegate assets from an operator. This is part of the withdrawal process initiated through the StrategyManager.

[if !supportLists]b. [endif]DelegationManagerStorage.sol

[if !supportLists]· [endif]The DelegationManagerStorage contract provides storage variables for the DelegationManager contract. The separation of storage from logic simplifies the upgrade process.

[if !supportLists]· [endif]The contract defines constants for EIP-712 typehashes for the contract's domain and delegation struct. EIP-712 is a standard for typed structured data hashing and signing, often used in Ethereum for structured data signing.

[if !supportLists]c. [endif]Slasher.sol

[if !supportLists]· [endif]As per its description, the Slasher contract is the primary slashing contract for EigenLayer. The functionalities include:

[if !supportLists]· [endif]Adding contracts with permission to perform slashing.

[if !supportLists]· [endif]Revoking permission for slashing from specified contracts.

[if !supportLists]· [endif]Tracking historic stake updates to ensure withdrawals can only be completed once no middlewares have slashing rights over the funds being withdrawn.

[if !supportLists]d. [endif]StrategyManager.sol

[if !supportLists]· [endif]The StrategyManager.sol contract appears to be a central component of the EigenLayer protocol.

[if !supportLists]· [endif]As per its description, the StrategyManager serves as the primary entry and exit point for funds within EigenLayer.

[if !supportLists]· [endif]It manages deposits into different strategies, enabling assets to be added or removed from strategies.

[if !supportLists]· [endif]It also handles the deposit of ETH into the settlement layer and the slashing of assets for specific strategies.

[if !supportLists]· [endif]is central to managing penalties and maintaining the integrity of the EigenLayer protocol. It provides mechanisms for registered operators to opt into slashing, for entities with slashing rights to freeze operators, and for the protocol to record stake updates. The contract ensures that non-compliant or malicious behavior can be penalized, thereby upholding trust and security within the ecosystem.

[if !supportLists]e. [endif]StrategyManagerStorage.sol

[if !supportLists]· [endif]StrategyManagerStorage acts as the foundation for the StrategyManager, holding essential storage variables, references to other contracts, and some system constants.

1. Middleware:

[if !supportLists]a. [endif]VoteWeigherBaseStorage.sol:

[if !supportLists]· [endif]The contract seems to be centered around managing the weights associated with various strategies during voting. The StrategyAndWeightingMultiplier struct and constants like WEIGHTING_DIVISOR indicate mechanisms to assign weights to strategies in voting scenarios.

[if !supportLists]b. [endif]VoteWeigherBase.sol:

[if !supportLists]· [endif]Manages how votes are weighed within the EigenLayer ecosystem. It interacts with strategies and quorums, ensuring that voting power is distributed according to predefined rules and weights.

[if !supportLists]c. [endif]RegistryBase.sol

[if !supportLists]· [endif]Register, De-register and updating the stakes of the operator.

[if !supportLists]d. [endif]PaymentManager.sol

[if !supportLists]· [endif]The contract seems to play a pivotal role in managing payments in the EigenLayer protocol.

[if !supportLists]· [endif]The contract manages interactive payment challenges. It provides mechanisms to handle and respond to payment claims, especially in scenarios where there might be disputes or fraudulent claims.

[if !supportLists]· [endif]This is an abstract contract meaning it doesn't implement all functionalities. The respondToPaymentChallengeFinal function is one such example, which is implemented in a contract inheriting from this one.

[if !supportLists]e. [endif]BLSRegistry.sol

specialized registry that uses aggregate Boneh–Lynn–Shacham (BLS) signatures for managing operator registrations using BLS signatures.

Note : The emphasis on BLS and the presence of aggregate public keys (apk) suggests that the protocol uses aggregated signatures for efficiency, reducing the size of individual signatures when many need to be processed or verified.

[if !supportLists]f. [endif]BLSSignatureChecker.sol

[if !supportLists]· [endif]Check the validity of aggregate operator signatures.

[if !supportLists]g. [endif]BLSPublicKeyCompendium.sol

[if !supportLists]· [endif]The contract provides a mechanism for operators in the EigenLayer ecosystem to register their BLS public keys.

[if !supportLists]· [endif]so the system can later use these keys to verify and validate aggregated BLS signatures from operators.

1. Pods:

[if !supportLists]a. [endif]EigenPodPausingConstants.sol

[if !supportLists]· [endif]Centralized Constants Management:

The contract serves as a centralized repository for constants used in the EigenPod system. Centralizing these constants ensures consistency and reduces potential errors.

[if !supportLists]· [endif]Pausing Mechanisms:

The constants in this contract appear to be related to different pausing functionalities for various operations. Pausing mechanisms are essential in smart contract systems to handle upgrades, emergencies, or detected vulnerabilities without affecting the entire system.

[if !supportLists]b. [endif]EignenPodManager.sol

Responsible for creating and managing individual EigenPods within the EigenLayer protocol.

[if !supportLists]· [endif]EigenPod Creation and Management:

[if !supportLists]- [endif]The contract provides functionalities to create new EigenPods.

[if !supportLists]- [endif]It manages the lifecycle of these EigenPods, handling operations like staking for new validators on EigenPods.

[if !supportLists]· [endif]Staking and Tracking:

The contract keeps track of the balances of all validators within EigenPods and their corresponding stake in the EigenLayer.

[if !supportLists]· [endif]Withdrawal Management:

It provides mechanisms to facilitate the withdrawal of ETH when such withdrawals are initiated by validators or other entities.

[if !supportLists]c. [endif]EigenPod.sol

Beacon Chain Interaction:

This contract interfaces with the beacon chain, a specific type of blockchain in Ethereum's sharding mechanism. It facilitates various functionalities, such as creating new ETH validators with specific withdrawal credentials and proving certain conditions from the beacon chain state roots.

Validator Management:

The contract provides functionalities for creating new ETH validators, ensuring their withdrawal credentials are directed to this contract.

Proofs and Verification:

Allows for proving from beacon chain state roots that specific withdrawal credentials are associated with this contract.

Also, provides means to prove the balances of ETH validators using the beacon chain state roots.

Balance Management:

The contract can update aggregate balances in the EigenPodManager.

Withdrawal Operations:

Facilitates the withdrawal of ETH when such withdrawals are initiated by validators or other entities.

[if !supportLists]d. [endif]DelayedWithdrawalRouter.sol

The primary function of this contract is to handle and facilitate delayed withdrawals. This mechanism ensures that withdrawal operations have a buffer period, providing an additional layer of security and allowing for potential audits or interventions if suspicious activities are detected.

[if !supportLists]· [endif]Withdrawal Delays:

The contract defines and manages a delay period (in blocks) for withdrawal operations. The delay can be adjusted by the contract's owner, within specified limits.

[if !supportLists]· [endif]Withdrawal Claims:

Users can claim their delayed withdrawals after the stipulated delay period has elapsed. The contract provides mechanisms to facilitate these claims.

[if !supportLists]e. [endif]BeaconChainOracle.sol:

Functions as an oracle to bridge the Beacon Chain's state to the Execution Layer of the Ethereum network.

[if !supportLists]· [endif]State Root Bridging:

The primary function of this contract is to provide a mechanism for bringing state roots from the Beacon Chain to the Execution Layer. This is essential for the interoperability and interaction between the two layers.

[if !supportLists]· [endif]Oracle Signer Management:

The contract owner can manage a set of 'oracle signers'. These signers have the responsibility of voting for specific state roots.

[if !supportLists]· [endif]Threshold Management:

There's a threshold mechanism in place, which dictates how many oracle signers must vote for a particular state root at a given block number before that state root is deemed 'confirmed'.

1. Strategies:

[if !supportLists]a. [endif]StrategyWrapper.sol

Minimalist strategy implementation in the EigenLayer ecosystem. It offers a secure way to wrap an underlying token, facilitating deposits and withdrawals without any additional logic. This simplicity ensures clarity and reduces potential points of failure.

it acts as a wrapper for the underlying token, facilitating deposit and withdrawal operations without any added logic or strategy.

Shares and Underlying Token:

The contract maintains a 1-to-1 correspondence between shares and the underlying token. This simplifies accounting and ensures that users get back the exact amount of the underlying token they deposited when they decide to withdraw.

[if !supportLists]b. [endif]Strategy.sol

Offers a foundational structure for strategies within the EigenLayer ecosystem. By managing the core deposit and withdrawal operations and providing a simple share-token relationship, it offers a starting point from which more complex strategy implementations can be developed.

[if !supportLists]· [endif]Strategy Foundation:

This contract serves as a foundation for strategies within the EigenLayer system. It provides fundamental functionalities like deposits and withdrawals and lays down a structure that other, more specialized strategies can inherit and build upon.

[if !supportLists]· [endif]Token Management:

At its core, this contract handles the management of an underlying token. Users deposit this token into the strategy and receive shares in return. When users want to withdraw, they can redeem these shares to get back the underlying token.

[if !supportLists]· [endif]Shares Management:

The contract maintains a correspondence between the underlying token and shares. This relationship ensures that the value of shares directly reflects the amount of the underlying token deposited.

1. Operators:

[if !supportLists]a. [endif]MerkleDelegationTerms.sol

Designed to manage the delegation terms for operators. It utilizes Merkle trees to facilitate the distribution of earnings to stakers. By allowing operators to post Merkle roots, stakers can claim their rewards efficiently using Merkle proofs. This method offers both transparency and scalability, ensuring that stakers can claim their rewards even if they do so infrequently. The contract serves as a bridge between operators and stakers, detailing the terms of delegation and facilitating the distribution of earnings.

[if !supportLists]· [endif]Earnings Distribution via Merkle Trees:

[if !supportLists]o [endif]Operators can distribute earnings to stakers by periodically posting Merkle roots. This mechanism allows for efficient and transparent earnings distribution, leveraging the properties of Merkle trees.

[if !supportLists]· [endif]Flexible Staker Earnings Claims:

[if !supportLists]o [endif]Stakers can claim their earnings based on the Merkle proofs provided by the operator. If a staker doesn't claim earnings regularly, they can still do so later with a cumulative claim based on updated Merkle roots.

[if !supportLists]· [endif]Specification of Delegation Terms:

[if !supportLists]o [endif]When a staker delegates their stake to an operator, they agree to the terms set in the operator's Delegation Terms contract. Payments to an operator pass through this contract for subsequent distribution to individual stakers.

1. Permissions:

[if !supportLists]a. [endif]PauserRegistry.sol

List or registry of addresses that have the authority to pause certain functionalities within the protocol to provide controlled and secure mechanism to halt certain operations, when necessary, for example, during upgrades, emergencies, or detected vulnerabilities.

[if !supportLists]a. [endif]Pausable.sol

Introduces pausability to a contract with high degree of granularity such as pausability using bit-flags. This means that different functionalities can be paused independently, offering a very specific control.

PART THREE: Deep Dive

There are 3 core functionalities that describes most of what EigenLayer does and can be used for. The functionalities are deposit flow, withdrawal flow and AVS interactions with EigenLayer and Operators.

Following are the key smart contracts that manages the above functionalities mentioned.

recordStakeUpdate

Slasher.sol

Stake

EigenPod.sol

Stake

EigenPod.sol

depositBeconChainETH

StrategyManager.sol

Deposits (Contract Flow):

There are 2 ways to deposit into EigenLayer:

Strategy Deposits via StrategyManager:

[if !supportLists]1. [endif]Depositor initiates deposit.

[if !supportLists]2. [endif]StrategyManager checks that the recipient isn't frozen.

[if !supportLists]3. [endif]Tokens are transferred to the chosen strategy.

[if !supportLists]4. [endif]Depositor is credited with shares from the strategy.

[if !supportLists]5. [endif]If the recipient has delegated to an operator, the operator's share amounts are updated.

Beacon Chain ETH Deposits via EigenPodManager:

[if !supportLists]1. [endif]Depositor initiates stake through the EigenPodManager.

[if !supportLists]2. [endif]An EigenPod is set up for the depositor if they don't already have one, which then stakes the ETH.

[if !supportLists]3. [endif]The EigenPod deposits the ETH into the Beacon Chain.

[if !supportLists]4. [endif]After the deposit, the depositor waits for an update from the Beacon Chain state root via the BeaconChainOracle.

[if !supportLists]5. [endif]Once updated, the depositor verifies their deposit, triggering a series of calls to update their Beacon Chain balance in EigenLayer.

Withdraw (Contract Flow):

Withdrawal from EigenLayer is a two-step process.

1.Queueing a Withdrawal:

Stakers initiate a withdrawal by specifying which strategies they want to withdraw from and the number of shares from each. They can also designate a different address to receive the withdrawn funds.

This initiation locks the funds but doesn't immediately remove them. If the staker is withdrawing all shares and opts for it, they can be immediately 'undelegated' from their current operator.

[if !supportLists]1. [endif]Staker initiates withdrawal with StrategyManager.queueWithdrawal.

[if !supportLists]2. [endif]System checks if the staker is 'frozen' due to penalties.

[if !supportLists]3. [endif]Necessary adjustments to shared amounts are made.

[if !supportLists]4. [endif]Details of the withdrawal are recorded.

2. Completing a Queued Withdrawal:

Once the staked funds are no longer active, the withdrawal can be completed. The receiver can opt to get the funds in tokens (for removal from EigenLayer) or in shares (for potential redelegation).

The completion process ensures the staked funds aren't subject to penalties.

[if !supportLists]1. [endif]Receiver completes the withdrawal via StrategyManager.completeQueuedWithdrawal.

[if !supportLists]2. [endif]System checks if the initial staker is 'frozen' due to penalties.

[if !supportLists]3. [endif]Depending on the receiver's choice, funds are either transferred as tokens or credited as shares.

AVS integration

EigenLayer provides a set of contracts for building AVSs. This includes base contracts like VoteWeigherBase and RegistryBase. For optimized signature checking, the BLS aggregate signature scheme is used through contracts like BLSPublicKeyCompendium, BLSRegistry, and BLSSignatureChecker.

High Level Integration Steps:

[if !supportLists]1. [endif]Opting into AVS: Operators opt into AVS using optIntoSlashing(..) and recordFirstStakeUpdate(..) functions. This allows operators to serve tasks for the AVS.

[if !supportLists]2. [endif]Stake Updates: Operators notify the AVS of any stake changes using the recordStakeUpdate(..) function, ensuring AVS is aware of stake dynamics.

[if !supportLists]3. [endif]Deregistering from AVS: Operators can deregister using recordLastStakeUpdateAndRevokeSlashingAbility(..) via the AVS's ServiceManager.

[if !supportLists]4. [endif]Slashing: AVSs can slash operators for misbehavior using a DisputeResolution contract which, upon a successful challenge, calls freezeOperator(..) to freeze the operator.

Additionally, Staker or Operators need to install off-chain software components of the particular AVS.

FAQ

1. What problem is being solved, or what service is being provided?

EigenLayer provides a foundational layer for actively validated services (AVSs), offering a framework for tasks to be managed and executed in a decentralized manner. The protocol ensures that tasks assigned to operators are carried out effectively, while also providing mechanisms for accountability, staking, and potential penalties for non-compliance.

2. Who are the actors in the protocol?

Operators: These are entities that commit to executing tasks for AVSs.

Stakers: Individuals or entities who deposit funds into the protocol. They can delegate their stake to operators to increase the security or efficiency of tasks.

AVS Providers: Services or platforms built on top of EigenLayer that assign and manage tasks.

3. What actions can the actors take?

Operators: They can opt into an AVS, manage and update their task commitments, and opt-out or deregister from an AVS. They are also at risk of being slashed for non-compliance or misbehavior.

Stakers: They can deposit assets, delegate their assets to operators, and withdraw their assets. They also benefit from the performance of the tasks and strategies they are involved in.

AVS Providers: They can register new tasks, manage existing ones, and have the authority to slash operators that misbehave or do not comply with the task requirements.

4. What is the lifecycle of a transaction?

The lifecycle varies based on the nature of the transaction:

Staking:

a. Stakers deposit assets into the protocol.

b. They delegate their assets to operators.

c. Over time, the staked assets may earn returns based on the performance of the tasks and strategies.

d. Stakers can then withdraw their assets and any returns they've earned.

Task Execution:

a. AVS Providers register tasks in the protocol.

b. Operators opt into these tasks.

c. Operators execute the tasks over the specified duration.

d. Upon task completion, operators report back, and the system evaluates their performance.

5. What incentives do the actors have?

Operators: They are incentivized by rewards or fees for successfully completing tasks. Their reputation and potential earnings are at stake, making them motivated to perform tasks diligently and avoid being slashed.

Stakers: They are incentivized by the potential returns on their staked assets. By selecting reliable operators and strategies, they can maximize their earnings.

AVS Providers: Their main incentive is to ensure that tasks are executed correctly and timely, as the reliability and efficiency of their service depend on it. Proper task management also helps maintain their reputation and trust within the EigenLayer ecosystem.