The Risks of Restaking: Slashing Cascades and Systemic Exposure
Restaking multiplies yield by putting the same capital to work across several protocols at once — but it multiplies the ways that capital can be slashed, too. A close look at where the compounding risk actually sits.
Selin AydinSecurity Editor · Crypto security, custody, exploits and smart-contract riskUpdated 14 June 2026
The short answer
Restaking multiplies yield by exposing the same stake to every service an operator has opted into, each with its own slashing conditions. The scenario that matters is correlated slashing — a bug in a widely used service, shared infrastructure, or a mass exit hitting many operators at once. Liquid restaking tokens add a further layer, and their exit runs through both a protocol escrow and Ethereum's own withdrawal queue.
Restaking's pitch is elegant: the same staked ETH secures Ethereum and, simultaneously, secures a handful of other services, earning extra yield for capital that was otherwise sitting idle beyond its base staking job. The risk side of that pitch is less often stated with the same clarity, and it deserves to be, because restaking doesn't just add yield on top of a fixed risk — it adds a new slashing condition for every additional service secured, and those conditions don't sit neatly apart from one another. Understanding the risks of restaking means tracing what actually happens to a unit of capital when it's committed to multiple services at once, and what happens to the wider system when a lot of capital is committed the same way.
Slashing risk doesn't stay contained to one protocol
A validator staking ETH natively faces one slashing condition: misbehave at the Ethereum consensus layer and lose a portion of stake. Restake that same capital to secure three Actively Validated Services and there are now four separate ways to get slashed — Ethereum's own rules plus whatever each AVS defines as punishable behaviour. Crucially, these conditions are not independent risks that simply add up in a predictable way. An operator's infrastructure failure — a misconfigured node, a bug in shared client software, a connectivity outage during a critical window — can trigger slashing conditions across multiple AVSs simultaneously if that operator was securing several of them with the same underlying stake. A single operational mistake, in other words, doesn't cost you exposure to one service; it can cost you exposure to all of them at once, because the restaked capital backing that mistake was never actually separated by service in the first place.
Restaking concentrates operational trust in a relatively small set of professional node operators, because running infrastructure reliably across multiple AVSs takes real expertise, and the market has predictably consolidated around operators with a track record. That concentration is efficient and also fragile in a specific way: if a handful of large operators secure a meaningful share of total restaked capital across a meaningful share of AVSs, then a bug in software those operators share, a cloud outage affecting a hosting provider several of them rely on, or a coordinated attack against operator infrastructure doesn't stay contained to one operator's clients. It can produce correlated slashing events across services that, on paper, look unrelated. Diversification across many AVSs doesn't help if the operators running those AVSs are drawn from the same shallow pool.
AVS quality varies enormously, and stakers rarely underwrite it directly
One of the least appreciated risks in restaking is that the staker bearing slashing risk is very often not the party evaluating whether a given AVS's code, incentive design, and operational maturity actually deserve that trust. Liquid restaking protocols that bundle exposure to a basket of AVSs make this worse by design — a staker seeking a simple, passive yield product ends up indirectly underwriting the security of services they've never inspected, built by teams whose track record ranges from rigorously audited to barely tested. An AVS with a subtle bug in its slashing logic, or one that defines slashable behaviour so loosely that honest operators get penalised for routine network hiccups, transmits that risk directly to the restaked capital behind it — and the people bearing that risk frequently learn about the specific AVS involved only after something has already gone wrong.
Liquid restaking tokens add a second, separate layer of risk
Liquid restaked tokens solve a real liquidity problem, but they don't eliminate the underlying slashing risk — they wrap it in an additional layer of smart-contract and market risk on top. The protocol issuing the token has its own contracts, its own admin keys or governance process, and its own potential for a bug or an exploit entirely separate from anything happening at the AVS level. Beyond that, liquid restaked tokens get used as collateral elsewhere in DeFi — in lending markets, in leveraged strategies, in liquidity pools — which means a slashing event, or even just uncertainty about whether one might occur, doesn't only affect direct stakers. It can trigger liquidations and de-pegs across every protocol that accepted the token as collateral, transmitting a restaking-specific problem into corners of DeFi that have no direct relationship with restaking at all.
There's a useful, slightly uncomfortable parallel here to rehypothecation in traditional finance — the practice of a bank or broker reusing the same collateral to back multiple obligations simultaneously. Rehypothecation works fine until it doesn't, and when it fails, it tends to fail in a way that's disproportionate to any single transaction, because the same asset was quietly standing behind more promises than it could actually cover if several of them came due at once. Restaking isn't identical — the mechanics are transparent and on-chain rather than opaque, and slashing is a defined, rules-based process rather than a bank simply running out of collateral — but the structural shape of the risk is the same: capital is being asked to stand behind more than one obligation at a time, and the system's safety depends entirely on those obligations rarely, if ever, being called on simultaneously. Regulators who spent the years after 2008 tightening rules around rehypothecation in traditional prime brokerage would recognise the shape of this problem immediately, even if the tooling used to manage it here is considerably newer and, in some respects, still catching up.
The systemic question: what happens at scale
Individually, a slashing event affecting one operator or one AVS is a contained, if painful, loss for the stakers delegated to that operator. The systemic question is what happens once restaking has grown large enough, and interconnected enough with the rest of DeFi through liquid restaked tokens, that a slashing event or a wave of correlated slashing events becomes large enough to move markets on its own — triggering liquidations in lending protocols, breaking peg assumptions in liquidity pools, and forcing a broader deleveraging that has nothing directly to do with the AVS where the original problem occurred. Ethereum's core validator set has spent years proving out its own security under real economic pressure; the AVS ecosystem built on top of restaking has, by comparison, had a fraction of that time and stress-testing, which means the tail risk here is still largely unpriced rather than genuinely understood.
What a careful staker actually checks
None of this means restaking is uniquely reckless — it means the diligence required is meaningfully heavier than ordinary staking, and worth doing explicitly rather than skipping because the yield looks attractive. Which specific AVSs is a given liquid restaking product actually exposed to, and has each one been audited independently rather than assumed safe because the platform hosting it is well known. How concentrated is operator exposure across those AVSs, and would a single operator's failure cascade across the whole basket. Has the liquid restaked token itself been used as collateral in other protocols the staker doesn't directly interact with, since that's where contagion tends to travel. And critically, is the yield being earned coming from real fee revenue an AVS is paying for genuine security, or from token emissions that will taper — because a slashing risk taken on for a subsidised yield that later disappears is a much worse trade than it looked at the outset. None of these questions are especially difficult to ask; they're simply easy to skip when a dashboard is showing a headline yield several points above ordinary staking, and skipping them is exactly how restaking's risks end up mispriced by the market for longer than they probably should be.
FAQ
What can restaking actually cost me?+
Principal. Your stake is exposed to the slashing conditions of every service your operator opted into, written by teams whose code you have probably not reviewed.
What is correlated slashing?+
Many operators penalised at once — through a bug in a widely used service, shared infrastructure, or a mass exit. It turns a survivable individual loss into a systemic one.
Do liquid restaking tokens add risk?+
Yes, a separate layer: the token contract, the protocol's operator and service selection, the exit mechanics, and secondary market depth if you need out before redemption.
What should I check before restaking?+
Which services my operator secures, the maximum penalty for each, whether slashing conditions are objectively provable, and the full exit path with its timing.