EigenLayer Improvement Proposals (ELIPs) are the primary mechanisms for proposing new features and upgrades to the EigenLayer core contracts. ELIPs are version-controlled design documents that detail the motivation, technical specification, rationale, implementation path, and impact evaluation of specific proposals impacting core contracts. The ELIP process is being introduced to provide the EigenLayer ecosystem with more transparency and clarity on upcoming changes.
What is Slashing?
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 enables 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).
This proposal 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.
Read the ELIP to gain an understanding and to bring back questions, feedback, and your thoughts in steering these designs.
So what?
With the release of the Slashing ELIP, we’re inviting everyone in the EigenLayer community to participate by reviewing the proposal and sharing your feedback in the comments below (or on Github). Your input will help us refine the proposal to ensure it aligns with user needs and expectations.
Unique Stake is a great suggestion because for Operators who run many AVS strategies, it makes sense to only penalize by the AVS as opposed to a full slash for the Operator. At its core this is isolating risk in a productive manner so that cascading slashing is prevented and only limited to the AVS where an Operator failed to perform its pledged duties.
Essentially AVS’ will be given the tools to properly reward honest and active Operators while punishing Operators in specific instances for failure to properly comply- but only specific to an AVS and not a full slash of all AVS’ that comprise a specific Operator. This puts necessary pressure on Operators to ensure they are meeting the standard of all AVS’ supported and for AVS’ to take a more granular approach for how they engage with Operators.
Question:
How long is the delay during the dereregistration process to ensure slashing takes place if necessary?
If I understand correctly, AVS’ will organize Operator sets and approach Operators with this information once they are ready to leverage this solution?
Hey Jonathan - thanks for the questions. Let me take a stab:
The deregistration process is actually instantaneous. It is designed this way so that Operator’s may immediately signal they are no longer ready to receive tasks (or for AVSs to remove Operators for one reason or another). A deregistered Operator may still be slashable!
Deallocation is primarily what makes Operator-allocated stake non-slashable. Deallocations are subject to the DEALLOCATION_DELAY, which is 14 days to ensure AVSs have the slashable stake they need. Deallocation is not coupled with deregistration. An Operator that wishes to remove slashable stake will need to deallocate that magnitude. They may also deregister, which will stop them from receiving new rewards from AVSs, and deregistration may trigger additional AVS logic around work distribution.
Yes, this is correct. The AVSs will organize how they want an Operator Set to run, with what requirements for Operators in that set, and what conditions they may want to apply as slashable (if any).
We want AVSs to be careful and considerate in this design, and, above all, communicative with existing and prospective Operators they want to work with.
Hope this helps - thanks for the questions! I will look to see where I can improve the ELIP text with this.
A transaction to execute the previously-queued timelock action was proposed to the Protocol Council multisig. This initial proposal was performed using Zeus, a tool developed by EigenLabs to aid in deployments and administrative actions (soon to be open source!). It followed the logic in the scripts within this folder. The previously-queued action can be found in the event logs of this transaction.
Protocol Council members proceeded to sign the proposed action via the (Gnosis) Safe UI, with the last (i.e. 3rd) signer executing the action.
Upon execution, the action triggered an upgrade of the:
AVS Directory (0x135dda560e946695d6f155dacafc6f1f25c1f5af) to the implementation deployed at 0xa396d855d70e1a1ec1a0199adb9845096683b6a2
Delegation Manager (0x39053d51b77dc0d36036fc1fcc8cb819df8ef37a) to the implementation deployed at 0xa75112d1df37fa53a431525cd47a7d7facea7e73
Rewards Coordinator (0x7750d328b314effa365a0402ccfd489b80b0adda) to the implementation deployed at 0xa505c0116ad65071f0130061f94745b7853220ab
Strategy Manager (0x858646372cc42e1a627fce94aa7a7033e7cf075a) to the implementation deployed at 0xba4b2b8a076851a3044882493c2e36503d50b925
All EigenPods (beacon at 0x5a2a4f2f3c18f09179b6703e63d9edd165909073) to the implementation deployed at 0xb132a8dad03a507f1b9d2f467a4936df2161c63e
EigenPod Manager (0x91e677b07f7af907ec9a428aafa9fc14a0d3a338) to the implementation deployed at 0x9801266cbbbe1e94bb9daf7de8d61528f49cec77
The EigenStrategy (0xacb55c530acdb2849e6d4f36992cd8c9d50ed8f7) to the implementation deployed at 0x90b074ddd680bd06c72e28b09231a0f848205729
All factory-deployed Strategy contracts (beacon at 0x0ed6703c298d28ae0878d1b28e88ca87f9662fe9) to the implementation deployed at 0x0ec17ef9c00f360db28ca8008684a4796b11e456
Strategy Factory (0x5e4c39ad7a3e881585e383db9827eb4811f6f647) to the implementation deployed at 0x1b97d8f963179c0e17e5f3d85cdfd9a31a49bc66