Loading article...
EigenLayer activated slashing on Ethereum mainnet on April 17, 2025, making an operator's elected stake allocation slashable by individual AVS operator sets under rules the AVS defines.
Plaque marking where Ethereum was invented. Photo: Oxyman via Wikimedia Commons (CC BY 2.0). Source
EigenLayer activated its slashing upgrade on Ethereum mainnet on April 17, 2025, after the EigenLayer Protocol Council's scheduled timelock. The change added operator sets and Unique Stake allocations, the two mechanisms proposed in the Eigen Foundation's merged ELIP-002. Eigen Labs described the release as live that day, rather than a testnet launch or a future roadmap item, and said the feature made it possible for AVSs, short for actively validated services, to attach economic penalties to an operator's service commitments in its mainnet announcement.
That activation did not turn every existing restaking position into slashable collateral. Eigen Labs said before the release that operators and stakers would not be automatically opted into slashing by AVSs the operators already ran; an operator had to choose the AVS conditions and take the steps required to participate. The company also said adoption would unfold over time rather than arrive across every AVS on the first day, a qualification that distinguishes protocol availability from an AVS actually using the mechanism for a particular operator (Eigen Labs, April 2, 2025).
The mechanics set boundaries around what has been opted in, when it can be penalized, and who can submit the penalty. They do not supply a universal list of offenses, a protocol-level appeal body, or an automatic escape from exposure once a staker or operator starts leaving. Those distinctions are central to how slashing affects delegated funds.
An operator set is identified in the protocol by an AVS address and a set identifier. The current AllocationManager documentation says an AVS creates a set with an identifier unique to that AVS and a list of strategies, which are the protocol's accounting representations for staked assets. The address-and-identifier pair is the set's key, and a set can be either redistributing or non-redistributing (AllocationManager documentation).
ELIP-002 describes the set as the level at which an AVS groups operators, assigns tasks, accepts Unique Stake allocations, and slashes for faults. An AVS can use separate sets for different work, hardware requirements, liveness expectations, or asset compositions; the proposal gives proof generation and proof verification as examples of tasks an AVS could separate. The protocol does not prescribe how an AVS must assign work within a set (ELIP-002, Operator Sets).
Before an AVS can create sets or register operators into them, it must register its metadata URI with AllocationManager. The current documentation says that metadata is emitted as an event rather than stored on-chain, and that the suggested metadata format is not validated on-chain. An AVS can also configure an AVSRegistrar contract to approve or reject registrations under its own rules (AllocationManager documentation).
Registration is therefore a separate action from allocation. An operator may register without allocating stake, and it may allocate to a set without being registered, according to the contract documentation. Actual stake is slashable only when the operator is registered, or remains in the post-deregistration slashable window, the relevant strategy belongs to the set, and the allocation's current magnitude is nonzero (AllocationManager documentation).
If an operator already has an active allocation to a set, registration makes that allocation immediately slashable. The registration call also invokes the AVS's registrar, if it has one, and that call must succeed for registration to complete. This lets an AVS impose its own eligibility test, such as a minimum allocation, while the protocol records the operator's membership (AllocationManager documentation).
Unique Stake is not a separate deposit pool controlled by an AVS. It is an accounting allocation of proportions of an operator's delegated stake, measured per strategy and tied to operator sets. ELIP-002 says only this opted-in Unique Stake is slashable by AVSs, and that it represents portions of stake delegated by stakers to the operator (ELIP-002, Unique Stake).
The protocol tracks the allocation through magnitudes. For each strategy, an operator begins with a total magnitude of 1e18; its maximum magnitude declines when the operator is slashed. The combined magnitude allocated across all sets for that strategy cannot exceed the operator's maximum magnitude, so allocations cannot add up to more than 100% of that strategy's stake (AllocationManager documentation).
That cap is the specific assurance behind the word "unique." If an operator assigns a portion of a strategy to one set, the same portion cannot simultaneously secure another set. ELIP-002 says an AVS can slash only the Unique Stake allocated to its own set; a slash from one set does not reduce the magnitudes allocated to the operator's other sets (ELIP-002, Slashing of Unique Stake).
The partition does not mean a staker manually assigns individual coins to each AVS. A staker delegates all of its assets to one operator at a time under the DelegationManager model. If that operator has an active slashable allocation for the staker's strategy, the documentation says a new delegation is immediately slashable to that extent; later deposits are also applied according to the existing allocation proportions (DelegationManager documentation).
ELIP-002 consequently describes a slash as reducing the funds of all stakers delegated to the affected operator in the affected strategies, in proportion to the slash. The protocol reduces the operator's allocation and total magnitude for the relevant strategy, while allocations to other sets retain their nominal magnitude. A staker's choice is to delegate to an operator, while the operator chooses the sets and allocations that make a share of the delegated position slashable (ELIP-002, Slashing of Unique Stake).
An operator sets an allocation delay before it can make its first allocation. That operator-selected delay applies globally across its strategies and sets. An initial delay setting, or a later change to it, is itself subject to the protocol's mainnet ALLOCATION_CONFIGURATION_DELAY of 126,000 blocks, which the documentation estimates as about 17.5 days (ELIP-002, allocation parameters).
Once the operator's own allocation delay has elapsed, a new allocation becomes active automatically. The amount must come from unallocated magnitude; it cannot be drawn from a pending allocation, an already allocated amount, or a pending deallocation. This means an operator cannot promise the same magnitude to a second set while the first commitment still encumbers it (ELIP-002, allocating and deallocating).
The exit path is deliberately slower where an allocation is currently slashable. On mainnet, a deallocation remains slashable for the 100,800-block DEALLOCATION_DELAY, estimated at about 14 days. A queued deallocation cannot be cancelled; after the delay it becomes non-slashable and the magnitude can become available for another allocation (AllocationManager documentation).
Deregistration does not queue a deallocation. An operator or the AVS can deregister the operator from a set, but any allocation to that set stays slashable for the same deallocation-delay window, and the operator cannot re-register for that set until the window has passed. The contract documentation says this is intended to prevent an operator from committing a slashable offense and immediately deregistering to avoid a penalty (AllocationManager documentation).
There are narrower cases in which a deallocation need not wait. If an allocation is no longer slashable because it no longer meets the protocol's eligibility criteria, a newly requested deallocation is freed immediately. That does not cancel a deallocation already pending, and an AVS removing a strategy after a deallocation has been queued does not erase the queued delay (AllocationManager documentation).
The set configuration can also alter exposure. The current documentation says an AVS may add strategies to a set, and an existing allocation to a newly added strategy becomes immediately slashable if the other conditions are met. It can remove strategies as well, but ELIP-002 cautions that operators should treat allocations to registered sets as potentially slashable at any time while they remain active (AllocationManager documentation).
The slashing upgrade made EigenLayer withdrawals subject to a 100,800-block mainnet minimum delay, approximately 14 days. A withdrawal is first queued and later completed; queuing removes the deposit shares from the staker's balance, but it does not make the position immune from slashing during the wait (DelegationManager documentation).
At completion, DelegationManager calculates the slashing factor at the withdrawal's completion block using the operator to which the staker was delegated when the withdrawal entered the queue. The resulting amount can be lower than the originally queued deposit shares if the operator was slashed during that interval. The staker may elect to receive the completed withdrawal as tokens or shares, but that choice does not remove the effect of any slash that occurred before completion (DelegationManager documentation).
Undelegation follows the same basic treatment: it queues withdrawals for the staker's deposited assets, and those withdrawals can be completed only after the minimum delay. This leaves a defined period in which a staker who has exited an operator relationship can still receive less than the queued amount if relevant slashing is processed (DelegationManager documentation).
ELIP-002 gives AVSs wide discretion over the reason for a slash. It says an AVS may slash an operator in one of its sets for any reason and that a condition does not have to be objectively attributable or proven on-chain. The proposal encourages AVSs to build their own governance, fraud-proof, or delay mechanisms, but says EigenLayer itself supplies no veto process (ELIP-002, Slashing of Unique Stake).
That is a limitation of the base layer rather than an assertion that every AVS lacks review procedures. Whether an AVS offers notice, a challenge period, independent verification, multisignature controls, or an appeal route depends on that AVS's design. The core contract checks membership, strategy inclusion, and nonzero active allocation; it does not impose a shared substantive definition of faulty service (AllocationManager documentation).
The authority that sends a slash is also set at the operator-set level. The current AllocationManager documentation says the v1.9.0 slashing upgrade introduced one slasher per set stored in AllocationManager; the newer creation parameters include a slasher address, while older set-creation calls use the AVS address as the slasher. The documentation lists a SLASHER_CONFIGURATION_DELAY, currently equal to the 126,000-block allocation-configuration delay, before a slasher change takes effect (AllocationManager documentation).
The distinction matters because the designated slasher can be an AVS-controlled address or another address selected by the AVS, rather than a protocol-wide committee deciding every incident. The contract documentation requires an AVS to have registered metadata before creating a set and rejects a zero-address slasher, but those setup checks do not evaluate the merit of a later slashing decision (AllocationManager documentation).
When a slash is processed, AllocationManager sends the resulting share directive to DelegationManager, which reduces the operator's delegated shares in proportion to the slash. The documentation says any still-slashable shares in the withdrawal queue are marked for burning or redistribution under the same proportion (DelegationManager documentation).
For standard, non-redistributing sets, the current contract documentation identifies the set's recipient as the default burn address. In a redistributing set, the AVS specifies a recipient when it creates the set, and that recipient cannot later be changed. A standard set cannot be converted to a redistributing one, and a redistributing set cannot have that property removed, according to ELIP-006.
The fund transfer is not necessarily the same transaction as the accounting slash. The StrategyManager documentation says slashed shares are recorded as burnable or redistributable, then may be cleared after a slash-resolution delay; anyone can call the clearing functions once that delay has elapsed, unless the clearing function is paused. This is separate from the operator's loss of shares recorded during the slash (StrategyManager documentation).
Redistribution has asset limits. Current contract documentation says a redistributing operator set cannot include the native-ETH strategy, and ELIP-006 additionally says EIGEN and native ETH are unsupported for redistributable slashing. The protocol's limitation concerns redistribution, not the existence of slashing itself: a standard set retains the default burn destination rather than an AVS-selected recipient (ELIP-006, Native ETH and EIGEN).
The contract materials also record precision limits. ELIP-002 says a very small slash may not produce an actual token burn because of rounding, leaving a small amount locked rather than fully burned. In the redistribution design, the Eigen Foundation similarly says rounding loss can leave dust in the protocol and produce a smaller distribution than a nominal calculation would imply (ELIP-002, slashing interface; ELIP-006, rounding).