Back to Blog 
Most writing about restaking risk collapses into a single sentence: "restaking is risky because you can get slashed." That sentence is true and nearly useless. It bundles together three failure surfaces that have nothing in common except that they all live in the same product. They break for different reasons, they hurt different people, and an auditor checks each one against a different list.
This post separates them.
Surface one is cryptoeconomic: slashing, and the redistribution variant that shipped in 2025, which quietly changed a key-compromise from a griefing problem into a theft problem. Surface two is market structure: how a liquid staking token or liquid restaking token loses its peg, why that has almost nothing to do with the token being "backed," and how a leverage loop turns a 6% discount into a liquidation cascade. Surface three is the smart-contract and mechanism layer: the withdrawal queue, the accounting around it, and the griefing attacks that treat a shared exit queue as a resource to exhaust.
If you only remember one framing, make it this: a single trigger can propagate up and down the stack. A slashing event is a cryptoeconomic fact, but the market reacts to it as a depeg, and users respond to the depeg by hammering a withdrawal queue that an attacker may already be griefing. The surfaces are distinct. The blast radius is not.
A quick grounding for the rest of the piece. Restaking lets already-staked ETH, or a liquid staking token wrapping it, secure additional services beyond Ethereum itself. On EigenLayer those services are AVSs. Stakers delegate to operators, operators opt into AVSs, and in exchange for extra yield they accept extra slashing conditions. Liquid restaking tokens (LRTs) wrap that restaked position into a transferable token, the same way a liquid staking token (LST) wraps a native staking position. Every "extra" in that paragraph is a new surface.
Surface 1: slashing, and the day it started paying attackers
For roughly a year after EigenLayer's mainnet launch, the protocol shipped without slashing at all. That was the loudest criticism it faced: a shared-security protocol with no enforcement is a promise, not a mechanism. Slashing went live on mainnet on 17 April 2025, at which point the protocol secured on the order of $7B across dozens of AVSs. Understanding what changed requires understanding what the old model got wrong.
The old model, and why it needed a veto committee
Originally, an operator opted into a subset of AVSs, and the operator's entire delegated stake was slashable by any of those AVSs. That single design choice created a chain of problems. An AVS sharing an operator inherited the slashing risk of every unrelated AVS that operator also served. No AVS had any guarantee of how much slashable stake actually stood behind it. To stop a single bad AVS from triggering systemic slashing, the protocol needed a common veto committee. And because that committee absorbed uncalibrated risk, AVS onboarding had to stay permissioned.
This is the model the systemic-risk critiques targeted, and it is worth being precise about the economic hole. If the same stake secures several AVSs, the cumulative gain from misbehaving across all of them can exceed the loss from a single slash. That is leverage, in the pejorative sense: the attacker's upside is the sum, the attacker's downside is one slash.
Unique Stake: isolating the blast radius
The current model breaks the coupling. An operator now allocates a percentage of its stake to an Operator Set, and a given unit of ETH is slashable by only one Operator Set at a time. Total allocation across sets runs from 0 to 100 percent, and the allocated portion is that set's Unique Stake, the amount exclusively slashable by that set. Because a set can only ever slash its own Unique Stake, slashing is localized, and the common veto committee disappears along with the need for it.
The cleanest way to feel the tradeoff is the worked example from the Stanford Blockchain Review analysis of the security model. Suppose an Operator Set has three operators with 100 ETH each, 300 ETH total. If the set weighs votes by Total Stake, a malicious operator manipulates a task's result by allocating just over 300 ETH, and because there is no slashable attribution, the only available punishment is ejection. If instead the set weighs votes by Unique Stake, that same attacker needs to allocate just over 30 ETH, and now that 30 ETH is slashable. Capital-to-attack drops from ~301 ETH to ~30.1 ETH, but the attack becomes punishable. That is the entire cryptoeconomic-security-versus-capital-efficiency dial, expressed in two numbers.
For an auditor, Unique Stake is a containment primitive, and it is important to be exact about what it contains. It isolates slashing attribution. It does not isolate the market's reaction, and it does not isolate panic. Hold that thought until Surface 2.
Redistribution: when a burn becomes a transfer
Here is the change that matters most and gets discussed least.
Originally, slashed funds were destroyed. Under EigenLayer's redistribution upgrade (ELIP-006), which reached mainnet in mid-2025, an AVS can instead route slashed funds to a
redistributionRecipient address. The stated motivation is legitimate: a protocol like a stablecoin issuer using restaked operators wants slashed stake redirected to make its users whole, not burned. The security consequence is that the risk model inverts.Under burn-only slashing, a compromised AVS slashing key is a destruction risk. Someone who steals the key can burn stake, which is bad, but they cannot take it. Under redistribution, EigenLayer's own documentation states the exposure plainly: an attacker who gains control of both the AVS slashing key and the
redistributionRecipient can drain the entire allocated stake of the Operator Set to an address they control. The slash is no longer a penalty. It is a withdrawal, made by the attacker, from everyone in the set.The protocol builds in specific hardening around this, and it is worth knowing exactly what each control does because an audit of any redistributable AVS lives or dies on them:
- The
redistributionRecipientis immutable once the Operator Set is created. An AVS can point it at an upstream proxy, but the immutability at the EigenLayer layer means any additional guarantees (timelocks, governance, further immutability) have to be enforced on that upstream contract. That upstream contract is now in your audit scope. - Redistributable Operator Sets and their operators are marked in on-chain metadata, so stakers can at least see the exposure.
- The operator's
ALLOCATION_DELAYis the staker's escape hatch. A compromised operator that registers for a malicious AVS cannot instantly expose delegated stake; the delay gives stakers a window to undelegate. Whether that window is adequate depends entirely on how fast monitoring catches the malicious registration, which is a post-audit monitoring question, not a contract question.
One implementation detail that is easy to miss and worth flagging in review: the slash is a two-step, deliberately non-atomic flow.
slashOperator marks shares as burnable or redistributable in the StrategyManager, and a separate permissionless call to clearBurnOrRedistributableShares moves them to the dead address or the recipient. The non-atomicity is intentional. It guarantees the slash itself never fails even if the downstream token transfer does. It also means there is a window between "marked" and "cleared" whose behavior you should reason about explicitly rather than assume.Asset scope at launch: LSTs and other ERC-20s are redistributable; native ETH and EIGEN are not. Native slashed ETH currently stays locked in the EigenPod contract (the burn-to-dead-address path for native ETH was gated on Pectra; verify its status before you rely on either behavior).
Objective, intersubjective, discretionary
Slashing on EigenLayer does not have to be objectively attributable on-chain. Some faults are provable by code, like double-signing. Others are intersubjective, resolved through the EIGEN fork-token mechanism and, ultimately, social coordination. This is precisely the fault line Vitalik Buterin drew in "Don't overload Ethereum's consensus" back in 2023: the further a slashing condition drifts from a purely mathematical fact toward a judgment call, the closer the system drags toward relying on L1 social consensus to recover, which is the systemic risk he argued the ecosystem should resist. His low-risk category is restaking built on objective attributability or no slashing at all; his high-risk category is everything that could force the community to fork to fix an application-layer failure.
A usable checklist item falls straight out of this: for every AVS slashing condition, classify it as objective, intersubjective, or discretionary. Then cross it with whether the set is redistributable. Discretionary-and-redistributable is the highest-risk quadrant that exists on this surface, because it combines subjective triggering with direct transfer of funds. If you find one, the mitigations you want to see are vetoable slashing, multisig control of the slasher, fixed and immutable conditions, and timelocks on anything upstream of the recipient.
How a slash reaches an LST
The cascade path is the reason this surface is not self-contained. In pure liquid staking, one protocol failing does not slash your stake somewhere else. In restaking, the shared stake means one AVS failure can slash an operator that serves many AVSs, and slashed native ETH reduces the underlying validator balance, which reduces the backing of any LST wrapping that validator, which nudges the LST's exchange rate down. Unique Stake is what stops the cryptoeconomic damage from spreading across unrelated AVSs. It does nothing to stop the market from repricing the LST, and it is the market, not the slash, that does the real damage. That is Surface 2.
Surface 2: depeg is a market-structure event, not a solvency event
The most common misconception about LST and LRT depegs is that they signal the token is not backed. Usually it signals the opposite: the token is fully backed and cannot be redeemed fast enough. An LST is fully collateralized. It does not face insolvency risk the way an algorithmic stablecoin does. What it faces is duration risk, and duration risk expresses itself as a discount.
The peg is held by arbitrage, not by liquidity depth
An LST trades on secondary markets where supply and demand set the price. It stays near par because arbitrageurs can buy the discounted token and redeem it for full value through the exit path. The peg is only ever as strong as that arbitrage, and that arbitrage is only ever as fast as the redemption queue.
The numbers make this concrete and slightly alarming. Analysis from Cork Tech puts stETH at roughly $39B in TVL against roughly $450M in AMM liquidity, of which only $10–20M can realistically exit at once without moving the price. The peg does not hold because you can dump stETH into a deep pool. It holds because arbitrageurs are willing to buy the discount and wait in the exit queue to capture the spread. The instant the queue's duration blows out, that arbitrage carries real duration risk, the arbitrageurs demand a bigger discount to compensate, and the floor sags. As one framing in that analysis puts it, if an asset goes from one-day duration to forty-five-day duration, it is no longer the same asset.
The canonical cascade: stETH, May and June 2022
The reference event for every LST risk model is still the stETH depeg during the Terra collapse, and it is worth walking because every ingredient recurs.
Before the Shapella upgrade, stETH had no redemption mechanism. You could not turn stETH back into ETH through Lido at all; you could only sell it. That removed the arbitrage floor entirely, which is the single most important fact about the 2022 episode and the reason it cannot happen the same way today.
On 12 May 2022, according to Nansen's reconstruction, Three Arrows Capital removed about $400M (128k stETH and 73k ETH) from the Curve stETH/ETH pool in a single transaction, and Celsius pulled roughly $380M the same day. Curve was the venue for stETH. Draining it meant large holders no longer had an exit at any reasonable price. stETH fell to around 0.935 ETH, a 6.5% deviation.
The discount itself was survivable. The leverage loop was not. The dominant stETH strategy was recursive: deposit stETH on a lending market like Aave, borrow ETH against it, buy more stETH, deposit again. That loop amplifies yield when the peg holds and detonates when it slips. As stETH fell, looped positions crossed their liquidation thresholds, forced sales of stETH deepened the discount, and the deeper discount liquidated the next tier of positions. Over $180M in stETH-collateralized positions were liquidated. If you have read our breakdown of flash-loan and liquidation-cascade mechanics, this is the same physics with a different ignition source: the trigger was a liquidity withdrawal and a broken arbitrage floor rather than a flash-loaned price push, but the reflexive liquidation spiral is identical. The same reflexivity drives the stability-pool liquidations and redemptions we walked through for Liquity.
Depegs run in both directions
A useful corrective to the "depeg equals panic" instinct: rETH spent parts of 2022 and 2023 trading above its reserve value. Before Rocket Pool's Atlas upgrade, spinning up a validator required 16 ETH of node-operator collateral, which throttled the creation of new rETH and produced a mint-side supply constraint, and therefore a premium. The academic systematics-of-knowledge work on LSTs documents this cleanly. The lesson for a reviewer is that a peg is a property of a mint-and-redeem mechanism, not a promise, and mechanism constraints move it in either direction. When you assess an LST or LRT, model both the redemption path and the mint path.
What LRTs add on top
Everything above applies to a plain LST. An LRT stacks more surface on top of it:
- More contract layers between you and the ETH: EigenLayer core, the AVS contracts, and the LRT wrapper. Any one of them can trigger a depeg independent of ETH's actual value, a point both Sigma Prime and Three Sigma make from their audit work.
- Some early LRTs shipped with no direct unstaking mechanism at all. That is the pre-Shapella stETH failure mode, reintroduced by choice. If the only exit is selling into a thin market, a rumor is enough to break the peg, and the withdrawal delay (on the order of a week at the EigenLayer layer) means even patient users may sell at a discount rather than wait.
- LRTs are widely used as collateral elsewhere. A run on one LRT that sits in another protocol's treasury or collateral pool is a contagion vector, a smaller-scale bank run that jumps protocol boundaries.
- The competitive dynamic itself is a risk. EigenLayer's own team warned against an "arms race of opaque risk-taking," where LRTs chase yield by taking hidden AVS or leverage risk that users cannot see and cannot price. On this surface, transparency is not a marketing nicety. It is a security property.
An LRT's exchange rate is also only as trustworthy as the oracle that reports it. An oracle that prices the token on fundamental backing while ignoring queue duration is the exact ingredient that turns a soft discount into a liquidation cascade.
Surface 3: the withdrawal queue is a shared resource, and shared resources get griefed
The third surface is where the auditor's day job lives, because it is made of contract logic and accounting rather than market psychology. The withdrawal queue exists for a good reason: EigenLayer imposes a delay on all liquid and native restaking withdrawals as a security measure, a window during which a disclosed vulnerability or anomalous behavior can be responded to before funds leave. But a delay applied to a shared queue is a resource, and resources get exhausted.
The griefing class
Get funded for your audit
Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.
No spam. Unsubscribe anytime.
Three Sigma's audit-grounded writeup on LRT risks lays out the canonical griefing pattern. A malicious actor repeatedly joins and exits in small increments to bloat the withdrawal queue, forcing many small withdrawals, exhausting gas, and keeping other users' funds locked longer than they should be. The timing variants are just as important: withdrawing just before a slashing event to dodge the penalty, or withdrawing and re-entering to escape being slashed at all.
The root cause is always one of two things. Either the cooldown or lockup logic fails to lock a user's stake for the entire window during which it is supposed to be at risk, which lets the timing dodges work, or the queue is structured so that one user can stall everyone else, which lets the bloat attack work. This is a denial-of-service pattern applied to a financial queue. The mitigations follow directly: lock stake through the whole at-risk period with no early-exit path, and design the exit queue so that per-user activity cannot monopolize it, for example with per-user queue caps and chunked processing.
Why the mechanism is fragile in the first place
Ethereum uses a dynamic withdrawal queue. It is more capital-efficient than the fixed-duration queues on other chains (Cosmos at 21 days, Polkadot at 28), but dynamic means stateful and complex, and complexity is attack surface. The mechanism-design literature on exit queues makes the comparison explicit: fixed-duration queues are simple and nearly impossible to grief but give a worse user experience, while dynamic queues buy efficiency at the cost of reasoning complexity.
Now stack the layers. EigenLayer imposes a protocol-wide escrow on top of Ethereum's own exit, and the two can run concurrently. An LRT then sits on top of EigenLayer, juggling withdrawals across multiple AVSs whose rewards are denominated in different tokens at different emission rates. This is the single messiest withdrawal surface in the entire staking stack, and it is exactly where accounting bugs hide. The same asynchronous-redemption complexity is why standards like ERC-7540 async settlement exist for vaults — request now, claim later, and get the accounting right in between.
Real bugs, not hypotheticals
The point of an audit-grounded post is to cite findings that actually happened. Sigma Prime's public writeup on liquid restaking reviews includes a Kelp finding (KLP2-01) that is a perfect specimen. During native-stake verification, the protocol was supposed to subtract a validator's staked amount from an internal
stakedButUnverifiedNativeETH accumulator. When 32 ETH is staked, the variable increases by 32 ETH; on verification it should decrease by the same 32 ETH. Instead, the code subtracted the validator's effective balance, which can be lower than 32 ETH. Every validator whose effective balance had dropped below 32 left a sliver of phantom ETH the protocol believed it owned. That is accounting drift, and accounting drift on an LRT is exchange-rate drift, which is a soft depeg the protocol cannot even see because its own books are wrong.The rest of the contract-layer checklist for this surface, drawn from the same body of audit work:
- Share-to-token and token-to-share conversions need consistent fixed-point math and edge-case tests at the extremes (dust-sized and whale-sized stakes). Rounding here lets users withdraw more than they are owed or leaves dust that accretes into a real number over time.
- Reentrancy across the withdrawal and delegation callbacks. Update state before external calls, apply
nonReentrant, and follow checks-effects-interactions. Because these contracts hold serious value, a single reentrancy bug is catastrophic rather than annoying. - Unbounded loops over a user's strategies, delegations, or pending withdrawals. If a withdrawal function iterates over an unbounded list, an attacker inflates the list until the function runs out of gas and blocks withdrawals entirely. Bound the iteration or process in chunks.
- Merkle-proof and beacon-chain-proof handling. When an LRT (or its oracle) supplies validator-exit proofs, a predictable tree structure is a spoofing target. Treat oracle-supplied proofs as untrusted input.
The queue is reflexive even with no attacker
The uncomfortable part is that the withdrawal queue produces a destabilizing loop on its own, and a griefer only has to nudge it at the wrong moment. The pattern documented during 2025's record exit-queue congestion runs like this: leveraged holders deleverage, they redeem the underlying ETH through the validator exit path, the queue spikes, the LST slips a few tenths of a percent below par, arbitrageurs join the queue to capture the spread, and the additional entrants make the congestion worse, which lengthens waits, which raises the opportunity cost of waiting, which motivates more selling. By early 2026, a wave of DeFi exploits pushed the Ethereum validator exit queue past 430,000 ETH. An attacker running the griefing pattern from earlier in this section does not need to manufacture this loop. The loop is already there. The attacker only has to lean on it while it is loaded.
What actually reduces the risk
Pulling the three surfaces back together, the mitigations sort cleanly by which surface they defend.
On the cryptoeconomic surface, Unique Stake and Operator Sets are the live containment for slashing blast radius, and they work as designed for what they cover. For redistributable sets specifically, insist on the hardening the protocol makes possible but does not mandate: an immutable recipient, timelocks and governance and immutability on any upstream contract the recipient points to, on-chain redistributable metadata so exposure is legible, and an
ALLOCATION_DELAY long enough that monitoring can catch a malicious operator registration before stakers are drained. Classify every slashing condition as objective, intersubjective, or discretionary, and treat discretionary-and-redistributable as a stop-and-escalate finding. Keep the whole design on the low-risk side of Vitalik's line: objective attributability or no slashing, and no slippery slope toward L1 social-consensus recovery.On the market surface, the highest-leverage fix is duration-aware pricing. An oracle that values an LST or LRT purely on its fundamental backing, ignoring current queue duration, is a liquidation engine waiting for a congested queue. Price the discount the way Pendle prices a PT, as a function of time-to-redemption. Never ship an LRT whose only exit is a market sell; build a real redemption path and be transparent about it. Keep loop collateral factors conservative and dynamic, because the loop is the cascade fuel. And run depeg early-warning as live monitoring rather than post-mortem material; changepoint-detection methods on Curve pool flow have been shown to flag a stETH depeg hours before it crosses 0.99, and the same approach caught the USDC SVB depeg roughly five hours early.
On the contract surface, the checklist is the one an engagement would actually run. Lock stake for the entire at-risk window with no withdraw-before-slash escape and no withdraw-and-re-enter dodge. Bound every loop over stakes, delegations, and withdrawals, and cap per-user queue activity so one actor cannot stall the set. Use fixed-point math with edge-case tests on every conversion, and verify native-stake accounting against the full 32 ETH rather than effective balance. Apply reentrancy guards and checks-effects-interactions across all withdrawal and delegation callbacks. Validate beacon-chain Merkle proofs against non-predictable structure and treat oracle-supplied proofs as untrusted. Monitor operator allocation changes and redistributable-set membership continuously, because on this stack the audit does not end at deployment. This is exactly the kind of layered review our defense-in-depth audit workflow is built for.
Restaking is not too dangerous to build on. It is three risk surfaces wearing one product's clothing, and the firms and protocols that survive the next congested-queue-plus-hack-wave will be the ones that audited each surface against its own list instead of against a single sentence about slashing.
Get in touch
Zealynx audits smart contracts, including restaking and liquid restaking protocols where the withdrawal-accounting and slashing-integration surfaces above are exactly the review scope. If you are shipping in this space and want a second set of eyes on the queue logic and the AVS slashing path, reach out.
Before you book, it is worth doing the prep that makes the review sharper — start with our pre-audit checklist so the engagement spends its time on the queue and slashing logic instead of the low-hanging fruit.
FAQ: restaking risk surfaces
1. What is restaking, and how is it different from staking?
Staking locks ETH to secure Ethereum itself and earn a base yield. Restaking lets that already-staked ETH — or a liquid staking token wrapping it — secure additional services on top of Ethereum for extra yield. On EigenLayer those services are called AVSs (Actively Validated Services). Stakers delegate to operators, operators opt into AVSs, and in return for the extra reward they accept extra slashing conditions. Each additional service the stake secures is a new failure surface, which is the whole reason restaking risk cannot be summarized in one sentence.
2. What is the difference between an LST and an LRT?
A liquid staking token (LST) is a transferable token representing a native staking position — stETH from Lido and rETH from Rocket Pool are the canonical examples. A liquid restaking token (LRT) wraps a restaked position, so it sits on top of an LST and adds more contract layers: EigenLayer core, the AVS contracts, and the LRT wrapper itself. Every one of those layers can trigger a depeg independent of ETH's actual value, and many early LRTs shipped with no direct redemption path, which reintroduces the pre-Shapella stETH failure mode by choice.
3. What changed with EigenLayer's redistribution upgrade (ELIP-006), and why is it dangerous?
Originally, slashed funds were burned (sent to a dead address), so a stolen slashing key was only a destruction risk — an attacker could burn stake but never take it. Redistribution lets an AVS route slashed funds to a
redistributionRecipient address instead. That inverts the risk model: an attacker who controls both the AVS slashing key and the recipient can drain the entire allocated stake of an Operator Set to an address they control. The slash stops being a penalty and becomes a withdrawal made by the attacker. Any audit of a redistributable AVS lives or dies on the recipient's immutability and the timelocks on whatever upstream contract it points to.4. Why does a liquid staking token depeg even when it is fully backed?
Because "backed" and "redeemable right now" are different properties. An LST is fully collateralized, so it does not face insolvency the way an algorithmic stablecoin does. What it faces is duration risk. The peg is held by arbitrageurs who buy the discounted token and redeem it through the exit queue — and that arbitrage is only as fast as the queue. When the queue's duration blows out, arbitrageurs demand a bigger discount to compensate for the wait, and the price sags. stETH holds roughly $39B in value against only $10–20M that can realistically exit at once, so the peg is an arbitrage property, not a liquidity-depth property.
5. What is a withdrawal-queue griefing attack, and how do you prevent it?
The withdrawal queue applies a security delay to all restaking exits. Because it is a shared resource, it can be exhausted. In the canonical griefing pattern, an attacker repeatedly joins and exits in small increments to bloat the queue, forcing many tiny withdrawals, burning gas, and keeping honest users' funds locked longer than intended. Timing variants let an attacker withdraw just before a slashing event to dodge the penalty. The fixes are to lock stake for the entire at-risk window with no early-exit path, cap per-user queue activity so one actor cannot monopolize it, and process withdrawals in bounded chunks so no unbounded loop can be forced out of gas.
6. What is Unique Stake, and how does it limit slashing blast radius?
Unique Stake is the portion of an operator's stake allocated to a single Operator Set, and it is slashable only by that set. In the old model, an operator's entire delegated stake was slashable by any AVS it served, so one bad AVS could trigger systemic slashing and every AVS inherited the risk of every other. Unique Stake breaks that coupling: a given unit of ETH is slashable by exactly one set at a time, so slashing damage stays localized and the shared veto committee is no longer needed. Crucially, it isolates slashing attribution — it does not stop the market from repricing the underlying LST, which is the damage that actually spreads.
Glossary
| Term | Definition |
|---|---|
| Oracle | On-chain data feed reporting off-chain values such as asset prices; the LST/LRT exchange rate is only as trustworthy as the oracle reporting it. |
| Flash Loan | Uncollateralized loan repaid in the same transaction, frequently the ignition source for the liquidation cascades that deepen a depeg. |
| Validator Set | The group of validators securing a network; slashed native ETH reduces validator balances and, in turn, the backing of any LST wrapping them. |
| Withdrawal Pattern | Design that lets users pull funds via a queue or claim step, the exact surface a griefing attacker tries to exhaust. |
| Restaking | Reusing already-staked ETH to secure additional services for extra yield, at the cost of additional slashing conditions. |
Get funded for your audit
Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.
No spam. Unsubscribe anytime.