Eigenlayer
Eigenlayer slashing losses scale with the stake allocated to an operator set
Updated on
Eigenlayer slashing reduces the restaked funds backing an operator set when its authorized slasher applies a penalty. The loss depends on each eligible strategy's active allocation and the fraction the slasher selects. Delegated restakers share the reduction, including eligible funds awaiting withdrawal. An AVS, or Autonomous Verifiable Service, defines its own commitments and enforcement logic. Exit requests preserve that exposure for a limited period, while burning or redistribution determines the slashed funds' destination.
An AVS penalty can reduce delegated restakers' backing while an exit request remains within its slashing window.
The allocated share sets the penalty's upper bound
A larger active allocation exposes more backing to the same slashing fraction. Each strategy accounts for a particular pool of restaked assets. An operator assigns part of that strategy's delegated backing to an operator set. The set's slasher can penalize that allocation, subject to membership and strategy eligibility. A penalty covering the entire allocation can exhaust the set's backing for that operator and strategy. It does not automatically exhaust the operator's entire delegated balance across every strategy.
Restakers delegate backing to an operator, and the operator allocates exposure to services. Their funds support its commitments even when they do not run service software.
Magnitude accounting connects the penalty to lost backing
The contracts use magnitude to represent an allocated share of backing. A slash changes this accounting before any later transfer of slashed tokens. The loss calculation distinguishes the set's allocation from the operator's remaining capacity.
Allocation magnitude determines the share at risk
For each operator and strategy, maximum magnitude starts at 10 18 and decreases after slashes. When the remaining maximum is nonzero, dividing a set's active magnitude by it gives its allocated proportion. Committed allocations cannot collectively exceed the remaining maximum. Prior penalties therefore matter when interpreting a magnitude value: the original baseline no longer supplies the correct denominator after slashing.
The penalty changes magnitude and shares
AllocationManager reduces the set's commitment
AllocationManager multiplies the active magnitude by the selected slashing fraction and rounds the removed magnitude upward. It subtracts that amount from the targeted allocation and the operator's maximum magnitude. A pending deallocation also shrinks proportionally, preserving the penalty within the amount awaiting release.
DelegationManager reduces withdrawable backing
DelegationManager converts the change in maximum magnitude into a reduction of delegated shares. Restaker accounting combines deposit shares with scaling and slashing factors to determine withdrawable shares. A raw deposit-share balance can consequently differ from the balance available for withdrawal. Strategy conversion then determines how many underlying tokens those remaining shares represent.
Who decides whether an operator fault deserves a slash?
The AVS defines its fault conditions and enforcement logic, and the operator set's designated slasher submits the penalty. A service can build verification or dispute handling around that authority. The core contracts enforce the allocation boundary and caller permissions; they do not independently evaluate every service's evidence or determine whether a submitted accusation is fair.
Since v1.9.0, each set has one slasher address stored in AllocationManager. Later replacements take effect only after the slasher configuration delay. The service can appoint a contract whose internal rules govern its calls. A contract address alone does not establish the quality of those rules. Earlier permission arrangements allowed multiple appointed callers, so the applicable slasher configuration matters when interpreting older integrations.
The slashing call requires an existing set, a slashable operator, eligible strategies, and valid fractions. Registration or its remaining post-deregistration window establishes operator slashability. A strategy also needs an active allocation for the call to deduct backing from it.
Unique stake separates commitments across operator sets
Unique stake assigns each portion of slashable backing exclusively to one operator set. Slashing one set reduces its allocated magnitude without reducing the magnitudes allocated to other sets. Because the operator's remaining maximum also falls, those unchanged allocations represent larger proportions of the remaining backing. Their nominal commitments remain intact through this accounting adjustment, subject to other changes affecting the backing.
Several services can still impose separate losses on their own allocations. A shared operator failure can breach several service commitments. The allocation boundary limits each set's reach; it does not prevent correlated faults across services.
Native ETH and token deposits retain different underlying risks
Native restaking combines AVS exposure with Ethereum validator balance accounting, while token strategies retain the properties of their underlying assets. For native ETH, EigenPodManager tracks beacon-chain balance decreases through a separate slashing factor. DelegationManager combines this factor with operator-side slashing when calculating withdrawable shares. A validator balance decrease and an AVS penalty can therefore both reduce the amount the restaker can withdraw. The two mechanisms have different causes and accounting inputs.
Liquid staking tokens retain their issuing protocol's validator and redemption dependencies. A liquid restaking token adds its own pooling and withdrawal arrangements. Holding such a token does not isolate its holder from losses in the backing pool. How an issuing protocol distributes those losses among token holders depends on its own accounting, separate from the operator-set boundary.
Burning and redistribution determine the funds' destination
Burning makes slashed assets inaccessible, while redistribution routes eligible slashed assets to the recipient a set specifies at creation. Mainnet slashing launched on April 17, 2025. Redistribution followed on July 22, 2025. It gives services a means to use penalties for purposes their own contracts define, including compensation arrangements. It does not automatically return the lost backing to the restakers who supplied it.
The choice belongs to the operator set's configuration. A standard set cannot later become redistributing, and a redistributing set cannot remove that property. Its redistribution recipient also remains fixed. Those constraints preserve the destination commitment operators accept when joining and allocating backing.
In the v1.13.0 implementation, redistributing sets exclude the native ETH and EIGEN strategies. Eligible token strategies can use redistribution. This asset restriction applies to redistribution, while native ETH and EIGEN can still back ordinary slashable allocations. In v1.13.0, EigenPodManager records slashed native ETH as burnable shares without a clearing or redistribution path. A compromised slasher or flawed service contract can impose losses within its authorized allocation, making the enforcement logic and recipient controls material parts of the exposure.
Allocation and settlement parameters govern different events
Ethereum mainnet uses block-based timing for allocation changes and delayed settlement. In v1.13.0, the ERC-20 settlement flow adds a separate slash resolution delay. Approximate day counts assume 12 seconds per block; the contracts enforce block thresholds.
| Parameter | Value or permitted setting | What it governs | Timing or accounting effect |
|---|---|---|---|
| maxMagnitude | Initially 10 18 per operator and strategy | Remaining allocation capacity | Decreases immediately when a slash executes |
| wadsToSlash | Greater than zero, up to 10 18 | Fraction of the active allocation to slash | One supplied fraction per selected strategy |
| ALLOCATION_DELAY | Operator-selected block count, including zero | Activation of allocation increases | Uses the operator's effective delay |
| ALLOCATION_CONFIGURATION_DELAY | 126,000 blocks on mainnet | Later changes to the operator's allocation delay | About 17.5 days |
| DEALLOCATION_DELAY | 100,800 blocks on mainnet | Slashable allocation reductions and post-deregistration exposure | About 14 days; the relevant block boundary controls release |
| SLASH_RESOLUTION_DELAY_BLOCKS | 50,400 blocks in v1.13.0 | Clearing newly recorded ERC-20 slashed shares | About seven days; clearing requires passing the resolution block |
Can queued funds still lose backing after an exit request?
Yes, queued withdrawals remain subject to operator slashing until their withdrawal slashability window ends. Queueing removes shares from active delegation, while the contracts retain separate records of still-slashable queued shares. A lower active delegated balance therefore does not establish that every exiting share has escaped the penalty.
Withdrawal accounting uses the operator recorded when the withdrawal entered the queue. The applicable window follows its start block and the contract's minimum withdrawal delay. Later AVS slashes cannot change that withdrawal's operator slashing factor after the window closes, even if completion happens later. Native ETH still has separate beacon-chain accounting and asset-availability conditions.
Operator deallocation and deregistration have their own boundaries. A slashable deallocation remains exposed until its effective block, and deregistration preserves a temporary slashing window. Neither action restores backing a prior slash removed. An allocation the set cannot currently slash can qualify for immediate deallocation, which makes the existing allocation's status relevant.
Allocation changes alter exposure on their effective blocks
An allocation increase takes effect after the operator's configured allocation delay. The activated portion becomes slashable if the operator remains slashable and the set includes the strategy. An operator can choose zero delay. Existing active allocations can also expose newly delegated or deposited backing immediately, without a fresh activation period for that deposit.
Version differences affect the first allocation-delay setting. From v1.9.0, a new operator's setting takes effect immediately during registration. Later updates wait through the allocation configuration delay. The delay before changing a setting and the delay before activating an allocation therefore describe separate clocks. Neither supplies a universal response period for restakers: the effective operator setting determines how quickly additional exposure can begin.
A recorded loss and completed settlement show different states
A successful slash reduces operator accounting immediately, while the ERC-20 token movement can occur later. The OperatorSlashed event identifies the operator, set, strategies, and penalty context. For ERC-20 strategies, the slash identifier connects the loss to the shares awaiting burning or redistribution. A description explains the submitted penalty without independently proving the allegation.
For newly recorded slashes under v1.13.0, StrategyManager sets a resolution block when it first records shares for that slash. Clearing must wait until the chain passes that block. Pre-upgrade entries with a zero resolution block retain their earlier clearing eligibility. Governance can pause burning and redistribution together, independently of deposits.
A settlement delay does not, by itself, reinstate the restaker's reduced claim.
A restaker interpreting the remaining balance needs the withdrawable-share figure. It includes the recorded deduction even while slashed tokens await transfer.
Popular questions about Eigenlayer slashing
Does a fresh deposit inherit an operator's previous slashing loss?
A new deposit does not retrospectively pay the operator's earlier slashing penalty. The deposit scaling factor adjusts for the operator's existing slashing factor when adding shares. Existing losses remain in the older position, and active allocations can expose the new backing to subsequent penalties immediately. A zero slashing factor is a separate constraint: adding shares through the fully slashed operator-strategy combination reverts.
What does the fraction in an OperatorSlashed event measure?
The event's wadSlashed value measures the removed magnitude against the operator's maximum magnitude before the slash. This differs from the input wadsToSlash, which selects a fraction of the targeted set's active allocation. Both use fixed-point scaling with 10^18 representing one whole unit. Interpreting the input as a percentage of every delegated asset would give the wrong denominator.
Can a slashing call succeed when one selected strategy has no active allocation?
A slashing call can skip a selected strategy whose current allocation magnitude is zero and continue processing other valid strategies. This avoids failing the entire call when an allocation has already cleared. The selected strategy must still belong to the set, and the caller, operator status, array ordering, and fraction inputs must satisfy the contract's other requirements.
Is a falling liquid restaking token price evidence of an AVS slash?
A lower market price alone does not establish that an AVS slash occurred. Liquid restaking tokens can trade below the value of their backing because market liquidity and redemption conditions affect their price. An AVS slash changes protocol accounting for an identified operator, set, and strategy. Token valuation also depends on the issuing protocol's accounting, so a market discount and a recorded loss require different explanations.
Must I approve each AVS penalty before it reduces my restaked funds?
Restakers do not sign a separate approval for each operator-set penalty. The operator selects service commitments through registration and allocation, and the designated slasher can enforce them against eligible backing. Delegation exposes the restaker to the operator's active allocations for the relevant strategies. A withdrawal request preserves exposure through its applicable slashability window.