| Author(s) | @matt.nelson on behalf of Protocol Council |
|---|---|
| Created | January 26th, 2026 |
| Proposal | [ELIP-013] |
| 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-013: Slashing UX Improvements
ELIP-013: Slashing UX Improvements
Summary of Feedback
Council is strongly supportive of ELIP-013. It is seen as a pragmatic, stakeholder-driven proposal that addresses long-standing slashing UX pain points, reduces configuration risk, and improves protocol operability while also laying groundwork for future upgrades. No council member recommends blocking or rejecting the proposal.
Noteworthy / Contentious Points
| Theme | Reviewer Observations |
|---|---|
| Slashing Upgrade Delay – Is it sufficient? | Sigma Prime (Kirk Baird representing Mehdi) raised the most important concern: if an AVS slashing contract is upgradeable (e.g., a proxy), an AVS could bypass the 17.5-day delay by upgrading implementation logic rather than changing the slasher address. He recommends explicit documentation or constraints stating that AVS slashing contracts should not be upgradeable or should themselves be subject to delays. |
| Delay vs. User Protection | Gonçalo Sá echoed a deeper version of this concern: a delay alone does not fully protect users unless they can meaningfully understand what changed in slashing logic. He suggests that delays should ideally be paired with clearer guarantees or more analyzable slashing behavior. |
| Single Slasher per OperatorSet | Jeff Commons views this as a major improvement: it reduces configuration error risk and allows AVSs to make more credible commitments around slashing logic. While technically “backwards compatible,” migration could affect AVSs with multiple slashers — but the ELIP notes (and Unit 410 verified via script) that no OperatorSets on mainnet currently have multiple slasher appointees, making this a theoretical rather than practical risk. |
| OperatorSet Migration Defaults | Unit 410 flagged the migration rule as noteworthy: if no slasher is set, the AVS address becomes slasher; if multiple exist, the first is chosen. They asked whether impacted AVSs had been engaged. The response confirmed that zero current OperatorSets meet these criteria, mitigating risk. |
| pauseAll() Power Concentration | Unit 410 highlighted that the pauser multisig is extremely powerful and that key management and incident response processes are critical. The response clarified that pauseAll does not add new powers, but simplifies an existing emergency process. Still noted as governance-relevant. |
| Instant Allocation Semantics | Unit 410 initially questioned whether instant allocation applied to only one AVS. Clarification confirmed that instant allocation can apply to multiple AVSs, constrained by an invariant that prevents multiple pending allocations per tuple. Reviewers generally agree this matches market needs and does not increase staker risk. |
| AllocationManager Split Pattern | Gonçalo Sá specifically requested confirmation that the split-contract pattern (introduced for code-size / maintainability reasons) is explicitly covered in audit scope. Unit 410 states audits were completed, but this remains a diligence point worth making explicit. This was specifically covered in the audit report and the auditors found no issues with the new pattern. |
Outcome
Pass – Broad Support with Documentation / Diligence Caveats
All reviewers recommend approval. The main non-blocking conditions to note for governance records are:
- Clarify or document expectations around upgradeable AVS slashing contracts to preserve the integrity of the slashing delay.
- Ensure audit scope explicitly covers the AllocationManager split architecture.
- Acknowledge the operational and governance sensitivity of pauseAll and its controlling multisig.