Restaking Isn't Free Yield. It's Every Risk You Already Took, Stacked.
Restaking turns idle staked ETH into yield for extra protocols. It also stacks slashing, contract, and correlation risk. Here's the rubric to grade any AVS.
Staking ETH secures one thing: the base chain. For that, you lock capital, run a validator, and collect a modest yield. For years that was the whole trade — safe, boring, capital-inefficient. Billions of dollars sitting there doing exactly one job.
Restaking looked at that idle capital and asked an obvious question: why should staked ETH secure only Ethereum, when it could secure a dozen other things at once, for a dozen more fees? Oracles, bridges, data availability layers, other rollups — all of them need economic security, and none of them wanted to bootstrap their own validator set from scratch. Restaking lets them rent yours instead. Your same staked ETH, cryptographically re-committed as collateral backing someone else's protocol, on top of the job it already had.
That's a genuinely clever piece of capital-markets engineering. It is not a Ponzi, not a shell game, not yield conjured from nothing. The yield is real because the service is real: you're taking on new, quantifiable obligations, and getting paid for it. Concede that much, because it's true.
Here's the part that gets lost in the "capital efficiency" pitch: efficiency and risk are the same lever, pointed in opposite directions. The reason that ETH was sitting idle wasn't incompetence — one job was the whole point, because one job is one way to lose your stake. Restaking doesn't discover free capacity. It sells off the safety margin, one additional obligation at a time, and calls the proceeds yield.
The Pitch, and Why It Isn't Wrong
Start with the honest version of what you're doing. When you restake, you're not depositing into a new pool of funds — you're extending the conditions under which your existing stake can be slashed. Your validator now attests to the correctness of an oracle feed, or a bridge's message-passing, or a rollup's data availability, in addition to attesting to Ethereum's chain state. Each additional service — each Actively Validated Service, or AVS, in restaking terminology — comes with its own slashing conditions, encoded and enforced by its own logic, layered on top of the base protocol's rules.
The economic argument for why this should exist is sound. Bootstrapping a new validator set from zero is slow and expensive; a new protocol has to convince strangers to lock up fresh capital, with no track record, for uncertain returns. Renting security from an already-decentralized, already-trusted validator set solves that cold-start problem instantly. It's the same instinct that makes reinsurance markets work: don't build new capital from scratch when there's underwriting capacity sitting idle that could take on the risk for a fee.
Reinsurance markets, though, spend enormous institutional effort modeling correlation — because the entire failure mode of reinsurance is writing what looks like ten independent policies that turn out to be one policy in disguise, all triggered by the same underlying event. That's exactly the discipline missing from most restaking positions today. Nobody's pricing the correlation. They're pricing the yield.
The Risk Stack Nobody Prices
The restaking pitch is usually presented as one number: an APY. That number is the sum of several structurally different risks, each capable of independently costing you your entire position, and none of them shows up separately on the dashboard.
Base slashing risk
This is the risk you already understood before restaking existed. Go offline too long, get slashed for downtime. Double-sign, get slashed for equivocation. It's small, well-understood, and it's the floor — not the whole building.
AVS-specific slashing
Every additional service you opt your stake into ships its own slashing logic, written by that service's team, audited to whatever standard that team could afford, and battle-tested for exactly as long as that service has existed — which, for most AVSs, is not long. A bug in that logic doesn't just fail to protect the AVS. It can trigger slashing conditions against validators who did nothing wrong, because the code that decides "did this validator misbehave" is itself the thing that's broken.
Scenario: an oracle AVS ships a faulty dispute-resolution module. A legitimate price update gets misclassified as an attack. The slashing conditions fire exactly as coded. Your stake — which was securing Ethereum correctly the entire time — takes a haircut because of a bug in software you never audited, for a service you may not have chosen directly if you restaked through an aggregator.
Smart contract and middleware risk
Underneath every AVS sits the restaking protocol's own contracts — the layer that tracks who's opted into what, enforces withdrawal delays, and routes slashing penalties to the right validators. That middleware is now one of the highest-value smart contract targets in the ecosystem, by construction: it doesn't hold one protocol's treasury, it holds the collateral backing potentially dozens of protocols simultaneously. A bug there isn't scoped to one AVS's blast radius. It's scoped to everything routed through it.
Operator risk
Most restakers don't run their own validators for every AVS they're exposed to — they delegate to node operators who run the infrastructure and opt into services on their behalf. That's a rational division of labor. It's also a trust handoff: you're now exposed to that operator's key security, their infrastructure uptime, their judgment about which AVSs are safe to opt into, and their incentive to chase the highest advertised yield rather than the most conservative risk profile — because higher yield is what attracts more delegators. The operator's incentives and yours are aligned on the way up and not obviously aligned on the way down.
Correlation and systemic risk
This is the one the "capital efficiency" framing hides best. The entire premise of restaking is that the same collateral backs multiple services at once. That's the feature. It's also, structurally, a concentration of risk that traditional finance would call something else: rehypothecation. The dollar amount of "security" the ecosystem appears to have isn't new money — it's the same money, counted once per AVS it backs. If a cascading failure hits a widely-used piece of shared infrastructure — the restaking middleware itself, or an AVS enough operators opted every delegator into for the yield — it doesn't stay contained to one protocol's users. It propagates across every service that was relying on that same restaked collateral, at the same time, because it was never actually independent collateral to begin with.
Liquid restaking token depeg risk
Liquid restaking tokens (LRTs) exist to solve restaking's liquidity lockup, the same way liquid staking tokens solved it for plain staking — you hold a tradeable receipt instead of illiquid, delayed-withdrawal capital. That receipt is only as good as the market's confidence that it redeems 1:1 for the underlying, under stress, on demand. Stack a slashing event across several AVSs onto an LRT and you get the same dynamic that has hit liquid staking tokens before: the peg holds fine in calm markets and comes under real pressure exactly when something has gone wrong upstream — which is precisely the moment holders most need it to hold.
Why the Usual Reassurances Don't Hold
"It's audited." An audit reviews the code as written against the properties the team told the auditor to check. It does not model how that AVS's slashing conditions interact with five other AVSs sharing the same underlying stake, because no single audit scope covers a validator's total cross-protocol exposure. Audited and uncorrelated are different claims. Only one of them is usually being made.
"Slashing has never actually happened at scale." Neither had a major stablecoin depeg, until one did. Absence of a loss event in a system's short operating history is not evidence the system is safe — restaking AVSs collectively have less runtime than most people's car insurance policies. A low base rate on a young population tells you the population is young, not that the risk is low.
"I only opted into one AVS, so my exposure is limited." True of the AVS-specific slashing risk. Not true of the middleware risk, the operator risk, or the correlation risk — all three sit underneath your one AVS choice regardless of how conservatively you selected it. Choosing one AVS carefully doesn't opt you out of the layers you didn't choose at all.
The Risk-Stacking Rubric
Score any restaking position by layer, not by headline APY. Net risk is the worst layer, not the average — a position with four low-risk layers and one high-risk layer is a high-risk position, because the attacker, the bug, or the cascade only needs the one weak layer to realize the loss.
| Layer | What can go wrong | Typical risk |
|---|---|---|
| Base validator | Downtime, equivocation | Low — well-understood, years of track record |
| Per-AVS slashing logic | Buggy or over-aggressive slashing conditions | Med–High — depends entirely on that AVS's maturity |
| Restaking middleware | Contract bug affecting all routed collateral | Med — small surface, very high blast radius if hit |
| Node operator | Key compromise, yield-chasing AVS selection | Med — depends on operator's track record and incentives |
| Cross-AVS correlation | Same collateral backing multiple failure-correlated services | High — rarely modeled, rarely disclosed |
| LRT wrapper | Depeg under stress, redemption backlog | Med–High — correlates with the layers above, not independent |
How to Actually Grade a Position
Run this before delegating meaningful stake, and rerun it whenever you add another AVS — because each addition changes the whole stack, not just one row.
- Count your actual AVS exposure. If you restake through an aggregator or an LRT, get the full list of every AVS your collateral is opted into, not just the headline one the product markets. Aggregation hides the count; the count is the risk.
- Read each AVS's slashing conditions, not its marketing. What specific, mechanical conditions trigger a penalty? How long has that logic run in production? Has it changed since launch — and if so, what changed?
- Ask who audited the middleware, and what was in scope. Cross-protocol interaction risk is rarely in an audit's stated scope. Confirm rather than assume.
- Know your operator's selection criteria. Do they cap the number of AVSs they'll opt your stake into? Do they publish a risk framework, or just an APY?
- Model the correlated case explicitly. If the restaking middleware or your operator's key were compromised, what's your actual loss — not your loss from any single AVS, but from every AVS your collateral simultaneously backs?
- Discount the yield by the least mature layer in your stack, not the average. A 6% blended yield sitting on top of one immature, unaudited-in-practice AVS isn't a 6% risk position. It's whatever that one AVS's failure costs you, wearing a 6% label.
The Honest Close
Restaking is a real financial innovation solving a real problem: idle, over-collateralized security capacity, sitting unused, when protocols downstream need exactly that capacity and are willing to pay for it. That's not hype. It's a legitimate capital markets function, and the yield compensates for a real service.
But "capital efficient" and "additional risk-free income" are not the same sentence, and restaking's marketing has spent considerable effort blurring the line between them. Every AVS you opt into is a new way to lose your stake, layered on top of the ways you could already lose it. The yield is the sum of those layers. So is the risk. Neither one nets out just because the dashboard only shows you the number that's going up.
Grade the stack before you chase the yield. Count the AVSs. Read the slashing logic. Ask what's correlated underneath the number that looks the same on every product's homepage. The capital efficiency is real. So is the fact that you can't unstack the risk after the cascade starts — only before.