| Author(s) | @abbey on behalf of Protocol Council |
|---|---|
| Created | Tues Apr 8, 2025 |
| Proposal | 0xdc887e76b5feb672814ed162a3595f4305ba4eb1f94d30c1fc47929b00dbca61 |
| Status | Approved |
This document is an official communication between the EigenLayer Protocol Council and the community. It aims to provide transparency with the EigenLayer ecosystem regarding upcoming protocol upgrades and network changes.
In this report, we present the outcome and evaluation of the Protocol Council’s review of ELIP-002: Slashing via Unique Stake & Operator Sets, ELIP-003: User Access Management (UAM), and ELIP-004: Slashing-aware EigenPods. These three ELIPs are being evaluated collectively as they comprise the full implementation of Slashing in the EigenLayer protocol.
What is Slashing?
EigenLayer is a platform for protocol participants to make credible commitments to one another. On EigenLayer, AVSs have tools to make economic commitments to their end users, such as proper or fair execution of their code run by Operators. With Rewards v2, EigenLayer enabled AVSs to issue rewards to Operators and Stakers when the AVS’ services are properly run (the carrot). With this Slashing upgrade, EigenLayer will give AVSs the ability to slash stake in instances where the commitments to properly run their services are provably broken (the stick).
ELIP(s) Overview
ELIP-002
Author(s): @matt.nelson, Yash Patil, Matt Curtis, Gautham Anant, Brett Palatiello, Bowen Li (all Eigen Labs)
ELIP-002 outlines an upgrade that strengthens the credible commitments AVSs can make to their users by penalizing (i.e. slashing) Operators for not properly running their services. These commitments are designed and deployed by AVSs, and can range from faults like incorrect computation, liveness failures, and more. Explicitly, this upgrade adds two new features to facilitate the slashing mechanism: Unique Stake and Operator Sets.
Unique Stake guarantees that an Operator’s specific slashable stake can be allocated only to one AVS at a particular time. This single pairing strengthens the AVS’s security without creating exogenous risk to other AVSs or the protocol at large. Operator Sets provide an in-protocol structure that enshrines the segmentation of Operators into local groups for the accounting, allocation, and slashing of staked security.
Together these features enable:
- Opt-in, task-specific slashing for Operators, where they may take on slashing risk in return for AVS rewards,
- Launching of more AVSs on mainnet, by giving them tools to make more cryptoeconomic commitments to their users,
- Use of the Unique Stake model by ecosystem participants to better understand risk, reward, and operating models for AVS infrastructure.
With Unique Stake and Operator Sets, Operators have fine-grained control over slashable stake in accordance with their acceptable risk and competencies. These unlock slashing, slashing unlocks the creativity of AVSs, and unlocking AVS creativity allows them to reach users and reward Stakers and Operators.
ELIP-003
Author(s): @matt.nelson, Zeyad Rajabi, Yash Patil (all Eigen Labs)
ELIP-003 introduces User Access Management (UAM) — a protocol-level feature in EigenLayer enhancing key management for Operators and AVS developers, such as allowing secure key rotation, revocation, and recovery. UAM will simplify AVS architecture in key ways, primarily through splitting of responsibilities of the ServiceManager. The protocol now demarcates specific functionality the root admin keys may appoint to new addresses, either EOAs or contracts. Similarly, admin keys themselves may be appointed or rotated.
Operators play a crucial role in securing the EigenLayer ecosystem by allowing stakers to delegate their assets to provide services to Actively Validated Services (AVS). To operate effectively, Operators and AVS developers rely on secure and efficient management of cryptographic keys:
- Operator Key: A smart contract or ECDSA key used for core functions, such as registration, reward claiming, slashable stake allocation, and fee management, requiring infrequent use.
AVS Operations Keys: Frequently used smart contract wallet or ECDSA keys used to manage operations-related functionality within the core protocol. - Operator AVS Signing Keys: Smart contract wallets, ECDSA, BLS, or other types of keys linked to an Operator for attestation and used for task verification logic in the AVS.
Current limitations in EigenLayer’s key management create several challenges for Operators and AVS developers:
- Security Risks: Limited key management, such as lack of key rotation, increases the risk of key theft, loss, and unauthorized access, impacting network integrity and risking slashing penalties.
- Operational Complexity: Managing multiple AVS keys, including their generation, storage, and rotation, increases the administrative burden and risk of errors, threatening both security and efficiency.
- Profitability Impact: Poor key management can lead to lost rewards and slashing events, which, when coupled with operational complexity, discourages Operators from managing multiple AVSs.
- Growing Demands for Best Practice: Adherence to cybersecurity best practices requires Operators (and AVS developers) to meet standards for secure key management and auditing. Without a robust key management system and a way to control permissions across a customer’s addresses, scalability, security, and efficiency are hindered across the EigenLayer ecosystem. The User Access Management feature aims to address these challenges by enabling secure access management with permissions control.
User access management is implemented at the protocol level with a security-first and user empowerment approach, ensuring robust, decentralized security controls integrated directly into the core infrastructure.
ELIP-004
Author(s): @matt.nelson, Alex Wade, Yash Patil, Matt Curtis (all Eigen Labs)
ELIP-004 upgrades EigenPods to account for a number of under-the-hood changes that implement the Unique Stake model, Operator Sets, and - as a product of those two - AVS slashing (read more in ELIP-002). It introduces targeted changes to the EigenPod contracts to make them slashing-aware and Pectra compatible. Upgrading Pods keeps natively restaked ETH functionally on-par with ERC-20s when used as slashable stake. The scope of this upgrade introduces breaking changes to EigenPods and updates several interfaces. Broadly, this upgrade brings:
- Slashing-aware EigenPod contracts that enable proper accounting for Native ETH slashings,
- The introduction of the Beacon Chain Slashing factor that propagates external Ethereum slashings correctly across EigenLayer,
- A new checkpoint structure,
- A pause on checkpointing around the time of the associated upgrade,
- A modified withdrawal process for EigenPods to apply Ethereum and/or AVS slashings to assets withdrawn from EigenPods.
Together, these upgrades properly account for the interactions between Ethereum and AVS slashings and ensure a smooth transition during the upgrade and withdrawal process.
In addition, the upcoming Pectra hard fork of Ethereum includes breaking changes to the proof generation library and adds execution-layer triggered validator withdrawals. This proposal includes upgrades that ensure that EigenPods remain functional after the hard fork.
Council Evaluation
The Protocol Council unanimously approves ELIP-002, ELIP-003, and ELIP-004 for execution. All five Council members plan on voting in favor of all three ELIPs. The Protocol Council agrees that all each ELIP meets the following criteria:
-
The proposal has been thoroughly audited by a qualified team, with all reported issues of medium or higher severity either resolved or acknowledged.
-
The proposal has undergone comprehensive testing.
-
An operational plan, including automated testing and safety checks, is in place.
-
The proposal advances the protocol and responsibly supports the growth of the EigenLayer ecosystem
-
The impact of the proposal has been fully and transparently considered by and communicated to relevant ecosystem stakeholders.
-
The proposal minimizes complexity, encapsulates new features as much as possible, and maintains credible neutrality.
-
The proposal does not compromise the overall security or reliability of the protocol.
-
The proposal has adhered to the established protocol governance process.
-
The development of the proposal has been conducted transparently alongside the broader EigenLayer ecosystem.
While reviewing these ELIPs, it is important to differentiate the capabilities EigenLayer provides AVSs from their implementation by AVSs. The former is within scope of this evaluation; the latter is not.
Evaluation: ELIP-002
ELIP-002 and the rest of the slashing ELIP series are a critical and much needed evolution for EigenLayer. Slashing is the logical next step after Rewards v2, addressing some significant gaps we’ve seen in the commitments Operators make to AVSs.
It delivers on the promise of the original EigenLayer whitepaper, with the added concept of Unique Stake introduced in order to deal with the systemic risk of contagion that was present in the original pooled stake model. ELIP-002 has garnered positive feedback from the community, reflecting strong support for its enhancements to the protocol’s security framework. We are particularly supportive of the introduction of Unique Stake and Operator Sets, which provide Operators with fine-grained control over slashable stake and enable AVSs to define custom security compositions. These features are instrumental in facilitating opt-in, task-specific slashing and in managing exogenous risks effectively.
We believe that ELIP-002 balances considerations from all of EigenLayer’s core stakeholders. Delegates can respond to operator adjustments before they are impacted by them thanks to in-protocol time delays. AVSs have the flexibility to source, reward, and penalize security provided by operators in accordance with their use cases.
In addition, we believe that slashing significantly strengthens the commitments AVSs can enforce, which not only makes sense from a risk mitigation perspective but also opens up new use cases for AVSs which are needed to support ecosystem growth.
Evaluation: ELIP-003
This proposal tackles an obvious pain point for Operators and AVS devs — key management. It’s clearly needed, and the setup EigenLabs has proposed for key delegation and rotation feels very practical and well-thought-out. Operators are empowered to allocate security to AVSs with fine-grained controls. Coming from Mike Reinhart at Unit410: “As an operator ourselves, we’re also delighted by the flexible key management solutions introduced by ELIP-003”. The UX improvements are clear and, more importantly, the security improvements brought on by the key rotation are major.
Evaluation: ELIP-004
ELIP-004 is an expected and required follow-up after ELIP-002. Making EigenPods slashing-aware makes sense and is clearly important for the long-term health and security of EigenLayer.
The changes to EigenPods in ELIP-004 are quite measured, with a focus on immediate compatibility with other slashing functionality, while deferring nice-to-have-but-complex features that are technically unblocked by the Pectra hard fork for a later, presumably smaller and more focused release. The proactive compatibility with the Pectra upgrade is also appreciated.
—
The approach taken in these ELIPs is broadly one of user optionality. The changes are generally backwards-compatible, so users can choose to continue the same behavior, but are also empowered to take advantage of the new functionality.
Yet while these ELIPs introduce new functionality, with them also comes new risks. By design, slashing presents new avenues for the loss – or perhaps more technically, destruction – of user funds. The access control changes in ELIP-003 also present new routes by which users can be phished and/or have their account partially or completely compromised. To deal with some of these fundamental risks, time delays for changes to slashing eligibility have been introduced in ELIP-002, and the scope of ELIP-003 has been somewhat contained. This approach seems to strike a prudent balance between introducing new features while maintaining security measures for users.
Despite a few notable edge cases remaining (as noted in ELIP-002 and ELIP-004 in particular), there has been adequate opportunity for testing and commentary for all three ELIPs. The changes have undergone public PR reviews by Eigen Labs employees, automated testing via Foundry, traditional audits including partial formal verification, and a large-prize-pool (the largest ever!) public audit contest on Cantina. On the security side, the Sigma Prime team conducted comprehensive security assessments of the proposed Solidity smart contracts and associated components. All issues identified have been resolved or acknowledged by the development teams. In particular, the discussion surrounding slashing edge cases led by Sigma Prime was very insightful. On the operational side, we expect a similar level of diligence, with testing and simulation tools, Eigen Labs’ open-sourced Zeus software and extensive manual review employed to ensure that the upgrade is completed safely and correctly.
In sum, this is a major step forward for the expressivity of EigenLayer’s stakeholders and the maturation of the protocol. We commend the rigorous testing and scrutiny applied to the related components and fully endorse this upgrade.
Additional Notes
- While the forum discussions around ELIP-002 were notably active and detailed, we’d like to highlight the need for ongoing transparency around slashing conditions and careful rollout. Slashing is powerful but carries inherent risks.
- The operational complexity of the slashing release should not be underestimated. We expect a careful phased deployment and transparent communications about the process from the Eigen Labs team, after its completion.
- There were great discussions on the forum in preparation for this release, but we would’ve liked to see discussion around the security considerations earlier in time. Transparency and thorough audits/testing are critical for major upgrades like this, and we would’ve liked to see the results of code reviews and post-code-review PRs published sooner.
- While ELIP-002 had adequate engagement from stakeholders, there was surprisingly lower engagement on both ELIPs -003 and -004. We’d like to encourage ELIP authors to explore ways to foment more engagement around upcoming upgrades.
- While there was a marked improvement from ELIP-001 we believe there is still room to improve our review and evaluation processes to better align with industry best practices. All improvements to Protocol Council processes will be discussed and disclosed on forum.eigenlayer.xyz.