ACE Journal

Restaking Risks in Shared Security Networks

Who this is for: validator operators, liquid restaking protocol engineers, and risk-conscious DeFi builders deciding whether and how to restake. The assumption is that you already understand Ethereum proof-of-stake, native slashing for equivocation and inactivity, and what a smart contract risk is. You do not need to have run an AVS. If you are weighing extra yield against extra slashing surface, or building a product that pools other people’s stake into AVSes, this is the failure surface you are signing up for.

The slash you did not opt into

Picture an operator running 2,000 validators. They have restaked into three AVSes for the extra yield: a data-availability layer, an oracle network, and a fast-finality bridge. For months it is free money on top of consensus rewards. Then one morning the bridge AVS pushes a faulty release. A condition that was supposed to penalize equivocating signers fires on a quorum of honest operators instead, because of an off-by-one in how the contract reads the operator set. Within one slashing transaction, a slice of stake across every operator restaked into that bridge is burned at once. Our operator did nothing wrong on the bridge. They are slashed anyway, and because the slashed stake was the same ETH backing their other commitments, their effective collateral on the data-availability AVS and the oracle just dropped too.

That is the shape of restaking risk, and it is structurally different from native Ethereum slashing. Native slashing punishes you for your own provable misbehavior: double-signing, or being offline during a mass slashing event. Restaking adds a second category, where you can be penalized for someone else’s bug in code you opted into but do not control, and where one penalty mechanically weakens your position everywhere else. The promise of restaking is capital efficiency, recycling one pile of stake to secure many services. The cost is that the same recycling turns independent risks into correlated ones.

The system has matured fast. EigenLayer turned on slashing on mainnet on 17 April 2025 through ELIP-002, which introduced Operator Sets and Unique Stake allocation [1][2]. Before that, slashing was not live and a global protocol veto committee was the proposed backstop against systemic over-slashing. ELIP-002 deliberately removed that committee: with Unique Stake, an AVS can only slash the specific stake operators have allocated to its Operator Set, so the systemic blast radius is bounded per AVS and a central veto is no longer required for the protocol to stay permissionless [2]. That is a genuine improvement over the pre-2025 design. It is not a solution to correlation, and conflating “my exposure to any single AVS is bounded” with “my portfolio is safe” is the most common and most expensive mistake operators make today.

How slashing exposure actually stacks

To reason about restaking risk you have to stop thinking about slashing as a coin flip per AVS and start thinking about it as a portfolio of penalties drawn against a shared collateral pool. Three mechanics drive it.

First, conditions stack independently. Each AVS defines its own slashing conditions in its own contracts, separate from Ethereum’s native rules. A validator restaked across n AVSes is simultaneously subject to n extra condition sets, many still young and audited unevenly. The probability of being slashed on at least one of them rises as you add AVSes. If each AVS independently has some probability $p_i$ of slashing you in a given period, the chance of escaping all of them is the product of the survival probabilities, so the probability of at least one slash is:

\[P_{\text{any slash}} = 1 - \prod_{i=1}^{n}(1 - p_i)\]

The plain-English gloss: even small per-AVS probabilities compound. Five AVSes at 1 percent each is not 1 percent of risk, it is about 4.9 percent of eating at least one slash. The whole point of equation (1) is that adding AVSes is not free even when each one looks safe in isolation.

Second, allocation is bounded but shared. Under Unique Stake, you allocate a magnitude of stake to each Operator Set, and an AVS can only slash up to what you allocated to it [3]. That caps any single AVS. It does not cap the sum. If you over-allocate across services, your committed magnitudes can exceed your free collateral, and a bad week across two AVSes can compound.

Third, slashing is not always objectively attributable. ELIP-002 made the slashing function maximally flexible: an AVS may slash any operator in its set for any reason, and the condition does not have to be provable on-chain [2]. AVSes are encouraged to add veto windows or delays to catch buggy or fraudulent slashes before they execute, but that is an AVS-by-AVS design choice, not a protocol guarantee. You are trusting each AVS’s own safety rails.

Figure 1 shows how a single operator’s stake fans out into multiple Operator Sets, and how a slash in any one of them draws down the shared collateral that backs the rest.

flowchart TD
    ETH[restaked ETH<br/>shared collateral] --> A[Operator Set: DA layer<br/>alloc 30%]
    ETH --> B[Operator Set: oracle<br/>alloc 25%]
    ETH --> C[Operator Set: bridge<br/>alloc 20%]
    A -. slash event .-> Burn[burned / redistributed stake]
    B -. slash event .-> Burn
    C -. slash event .-> Burn
    Burn ==> Drain[effective collateral<br/>drops for every set]

Figure 1. How one operator’s restaked ETH is allocated across three Operator Sets, and how a slash in any set reduces the shared collateral backing the others. Look at the bottom arrow: the drain is the coupling that turns three independent bets into one correlated position.

Worked example: modeling correlated slashing exposure

The right way to size restaking risk is to compute the maximum aggregate slash you can suffer in a correlated bad event, not the expected slash under independence. Start with the on-chain primitive. Under ELIP-002, an AVS slashes by calling the AllocationManager with a fraction of the operator’s allocated magnitude for that Operator Set. A simplified view of the call surface looks like this:

// Simplified shape of the EigenLayer AllocationManager slashing entrypoint.
// An AVS can only slash stake allocated to one of its own Operator Sets,
// and only up to wadToSlash (1e18 == 100% of the allocation).
struct SlashingParams {
    address operator;       // operator being slashed
    uint32  operatorSetId;  // which set (i.e. which AVS service)
    uint256[] wadToSlash;   // fraction per strategy, 1e18 = 100%
    string  description;    // need not be on-chain attributable
}

function slashOperator(
    address avs,
    SlashingParams calldata params
) external returns (uint256 slashId, uint256[] memory sharesSlashed);

The two fields that matter for risk are operatorSetId, which scopes the slash to one AVS, and wadToSlash, which is the fraction of your allocation that AVS can burn. Your exposure to one AVS is its wadToSlash ceiling times what you allocated to it. Your portfolio exposure is the sum across AVSes, adjusted for which ones can fail together.

That adjustment is the whole game, and it is exactly the question the academic literature has started to formalize. Durvasula and Roughgarden’s “Robust Restaking Networks” models a restaking graph and shows that robustness depends on an overcollateralization buffer between attack cost and attack profit: if attack costs always exceed profits by some margin, a small initial stake loss cannot cascade into a large one [8]. The practical translation for an operator is to refuse to model AVSes as independent and instead bound the worst correlated case.

Here is a compact model that does that. It computes both the naive independent expectation and a correlated worst case, where AVSes in the same correlation group are assumed to slash together:

from itertools import groupby
from operator import attrgetter

class AvsExposure:
    def __init__(self, name, allocation_eth, max_slash_wad, p_slash, group):
        self.name = name
        self.allocation_eth = allocation_eth      # ETH allocated to this set
        self.max_slash_wad = max_slash_wad        # worst-case fraction, 0..1
        self.p_slash = p_slash                    # per-period slash probability
        self.group = group                        # correlation group label

    @property
    def max_loss(self):
        return self.allocation_eth * self.max_slash_wad

def expected_independent(portfolio):
    return sum(a.allocation_eth * a.max_slash_wad * a.p_slash for a in portfolio)

def correlated_worst_case(portfolio):
    # AVSes sharing a group (same client, same operator set, same audit firm)
    # are assumed to slash together: take the full group loss as one event.
    by_group = groupby(sorted(portfolio, key=attrgetter("group")),
                       key=attrgetter("group"))
    return max(sum(a.max_loss for a in g) for _, g in by_group)

Run it on the operator from the hook. They have allocated stake to three AVSes, and two of them, the oracle and the bridge, share an upstream client library, so a bug in that library would plausibly slash both:

portfolio = [
    AvsExposure("da-layer", allocation_eth=600, max_slash_wad=0.50,
                p_slash=0.01, group="da"),
    AvsExposure("oracle",   allocation_eth=500, max_slash_wad=0.50,
                p_slash=0.02, group="shared-client"),
    AvsExposure("bridge",   allocation_eth=400, max_slash_wad=1.00,
                p_slash=0.02, group="shared-client"),
]

print(round(expected_independent(portfolio), 1))   # 11.0 ETH expected
print(correlated_worst_case(portfolio))            # 650 ETH worst case

The expected loss under independence is about 11 ETH, a number that looks tame and is the number a careless dashboard will show you. The correlated worst case is 650 ETH, because the oracle and bridge share a client and the model treats their full allocations as one joint event. The gap between 11 and 650 is the entire point. Sizing your ceiling against the 11 is how operators get wiped out; sizing against the 650, and refusing to over-allocate into a single correlation group, is how you survive the first real AVS failure. The group label is doing the heavy lifting, and assigning it honestly, by shared client, shared operator set, shared audit firm, shared chain dependency, is the analytical work that no contract enforces for you.

The hard part: correlation is invisible until it fires

The non-obvious lesson, the one operators only learn by living through an incident or watching someone else’s, is that the dangerous correlations are the ones that do not show up on any allocation screen. Unique Stake gives you a clean, legible number for per-AVS exposure, and that legibility is seductive. It tempts you to believe that because each AVS is individually bounded, your portfolio is diversified. It usually is not, because diversification in restaking is about shared failure modes, not about the count of distinct AVSes.

Consider where hidden correlation actually lives. AVSes built by the same team tend to make the same mistakes. AVSes audited by the same firm share that firm’s blind spots. AVSes that depend on the same oracle, data-availability layer, or off-chain client binary fail together when that dependency does, even though on paper they are separate Operator Sets with separate conditions. A liquid restaking protocol that markets “exposure to 12 AVSes” may, underneath, hold three or four genuinely independent failure domains. The number that matters is the count of independent failure domains, not the count of AVSes, and the protocol almost never publishes the former.

This is also where the removal of the global veto committee cuts both ways. Pre-2025, a central committee could in principle halt an erroneous mass slash before it executed, at the cost of being a trusted, centralized bottleneck. ELIP-002 replaced that with per-AVS isolation and optional, AVS-defined veto or delay windows [2]. That is more permissionless and more honest about where trust lives, but it also means there is no longer any global circuit breaker. Whether a buggy slash can be caught and cancelled now depends entirely on whether the specific AVS you are in implemented a delay window, and on how long that window is versus how fast the bug fires. So read each AVS’s slashing design and ask one concrete question: if this contract slashes me incorrectly at 03:00, is there a governance-shaped gap before the burn is irreversible, and is it long enough for anyone to notice?

Integration: where this sits in an operator’s workflow

In practice, modeling slashing exposure is not a one-time spreadsheet. It is a control that lives in the loop between “an AVS wants my stake” and “I allocate.” A workable day-to-day shape:

When evaluating a new AVS, read its slashing specification, not its marketing, and extract three things: the conditions under which it slashes, the maximum wadToSlash it can apply, and whether it has a veto or delay window. Assign the AVS a correlation group based on its team, auditors, and upstream dependencies. Add it to the portfolio model and re-run the correlated worst case. If allocating to it pushes any single correlation group’s worst-case loss above your hard ceiling, you do not allocate, or you reduce an existing allocation first. Figure 2 shows that gate as a decision loop.

flowchart TD
    New[new AVS wants stake] --> Spec[read slashing spec:<br/>conditions, max wadToSlash,<br/>veto window?]
    Spec --> Group[assign correlation group:<br/>team, auditor, deps]
    Group --> Model[re-run correlated<br/>worst case]
    Model --> Check{group worst case<br/>over ceiling?}
    Check -- yes --> Reject[do not allocate<br/>or trim existing]
    Check -- no --> Alloc[allocate]

Figure 2. The allocation gate as a repeatable decision loop. Look at the diamond: the deciding test is the correlated worst case per group, not the per-AVS number, which is why a tempting new AVS can still be rejected.

Liquid restaking protocols carry the same model but at one more remove, because they pool depositors. An LRT issuer is making the allocation decisions on behalf of token holders who cannot see the Operator Sets directly. That makes published exposure dashboards a governance necessity, not a nicety. Figure 3 traces the flow of risk from a depositor’s LRT down through the protocol’s allocations into the AVSes, and back up as a mark-to-market hit when a slash lands.

sequenceDiagram
    participant H as LRT holder
    participant P as LRT protocol
    participant O as operator set
    participant A as AVS contract
    H->>P: deposit ETH, mint LRT shares
    P->>O: delegate + allocate across AVSes
    O->>A: register in Operator Set
    A-->>O: slash event (bug or attack)
    O-->>P: allocated stake burned
    P-->>H: ETH-per-share drops, redemption queue lengthens

Figure 3. The path of slashing risk from an LRT holder down to an AVS contract and back. Look at the final two arrows: the holder absorbs a loss they never chose and may not be able to exit immediately because redemption is queued, not instant.

The redemption queue is the part holders underestimate. An LRT is not cash. Unwinding it means going through the protocol’s withdrawal path, which inherits Ethereum’s exit and EigenLayer’s escrow delays, and which can stretch during a rush. If a slash drops the ETH-per-share ratio, holders who bought in at a higher ratio take an immediate mark-to-market loss, and the secondary-market price of the LRT can fall below its redemption value on sentiment alone. That gap invites forced selling and the same reflexive feedback loops the industry watched play out in algorithmic-stablecoin de-pegs. The defense is for issuers to publish their AVS selection criteria and live slashing-exposure dashboards, and for holders to treat a quoted “redemption value” as conditional on a queue, not a guarantee of liquidity.

Restaking is one answer to a broader question: how does a new protocol bootstrap economic security without standing up its own validator set and token? It is worth placing it against the obvious alternatives, even-handedly.

Native staking with no restaking is the conservative baseline. Your only slashing surface is Ethereum’s own, which is well understood, narrowly scoped to provable faults, and has years of operational track record. You forgo AVS yield, and any new protocol you might have secured has to find its security elsewhere. For an operator whose mandate is capital preservation over yield, this is frequently the correct choice, and restaking advocates sometimes undersell how reasonable it is.

Cosmos-style interchain security lets a provider chain’s validator set secure consumer chains, sharing security at the chain level rather than the individual-stake level. It solves a similar bootstrapping problem within one ecosystem, with a more uniform, governance-mediated validator set and slashing regime. The trade is that it is largely confined to the Cosmos ecosystem and offers less of an open market for arbitrary services to rent security on demand, which is exactly the openness EigenLayer optimizes for.

Symbiotic and other restaking protocols pursue the same shared-security thesis as EigenLayer with different collateral and curation models, for example admitting a broader set of collateral assets and leaning on third-party “curators” or “vaults” to manage allocation. The risks rhyme: every shared-security design that recycles collateral across services inherits the correlation problem, regardless of whose contracts implement it. Choosing among them is mostly about whose curation, collateral, and governance assumptions you trust, not about whether the fundamental coupling goes away. It does not.

The honest summary is that restaking buys a permissionless market for economic security at the price of correlated, hard-to-see slashing risk, and the alternatives mostly trade away some of that openness to get a simpler, more legible risk surface. There is no design here that gives you the capital efficiency without the coupling.

Where it breaks

Restaking fails in recognizable ways. Knowing them up front is most of the defense.

Correlated slashing across shared dependencies. The headline failure: AVSes that look independent share a client, an auditor, or an upstream oracle, and a single bug slashes all of them at once. Per-AVS Unique Stake bounds each allocation but does nothing about how many allocations get hit together. If you size your ceiling against independent expectation rather than correlated worst case, this is the event that wipes you out.

Slashing contract bugs with no adequate veto window. Because slashing need not be objectively attributable [2], a faulty release can burn honest operators’ stake. If the AVS implemented no delay window, or one too short for anyone to react, the burn is irreversible. The removal of the global veto committee means there is no longer any protocol-level backstop to fall back on, so this risk now lives entirely in each AVS’s own design quality.

Over-allocation beyond free collateral. Committing magnitudes across many Operator Sets without tracking the aggregate is how operators discover, mid-incident, that two simultaneous slashes leave them unable to honor their remaining commitments. The cap is per-AVS; the discipline of keeping the sum sane is on you.

LRT de-peg and redemption-queue gridlock. A slash that lowers ETH-per-share, combined with a withdrawal rush, can push an LRT’s market price below redemption value and trigger reflexive selling while the redemption queue is too long to arbitrage the gap away. Holders who treated the token as cash-equivalent learn it is a leveraged, queued claim.

Systemic feedback into Ethereum’s base layer. This is the tail risk the whole ecosystem is watching. If a major AVS failure forces a large, correlated slash and a wave of validator exits, the pressure does not stay contained to that AVS. It can spill into Ethereum’s own validator set and exit queue, which is the scenario that makes restaking a question of network-level systemic risk and not just an operator’s private bet. Nobody has seen this at full scale yet, which is precisely why it deserves respect.

Governance and key-management risk at the AVS layer. Many AVSes retain upgradeable contracts and privileged roles in their early life. A compromised or coerced admin key on an AVS you are restaked into is a slashing vector that no amount of correlation modeling on the published conditions will catch, because the published conditions are not the real attack surface when the contract can be upgraded under you.

Further reading

Start with the EigenLayer whitepaper [4] for the original shared-security thesis, then read ELIP-002 [2] and the slashing concept docs [1] to understand what actually shipped to mainnet in 2025, including Operator Sets, Unique Stake, and the deliberate removal of the global veto committee. The Unique Stake reference [3] is the precise statement of how per-AVS isolation bounds exposure. For the theory of when restaking is robust, Durvasula and Roughgarden’s “Robust Restaking Networks” [8] gives the overcollateralization-buffer result that motivates worst-case rather than expected-case sizing, and the follow-on work on Sybil-proofness [9] extends it. For independent risk framing aimed at practitioners, the LlamaRisk survey of restaking in DeFi [5] and BlockSec’s security-perspective writeup [6] are even-handed. For redistribution mechanics, read ELIP-006 [7]. Finally, treat the Ethereum staking documentation [10] as the baseline against which all of this added risk should be measured.

Written with AI assistance, editorially reviewed.

References

[1] EigenLayer, “Slashing Concept Overview.” https://docs.eigencloud.xyz/products/eigenlayer/concepts/slashing/slashing-concept

[2] EigenLayer Foundation, “ELIP-002: Slashing via Unique Stake and Operator Sets.” https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md

[3] EigenLayer, “Unique Stake.” https://docs.eigencloud.xyz/products/eigenlayer/concepts/slashing/unique-stake

[4] EigenLayer, “EigenLayer: The Restaking Collective (Whitepaper).” https://docs.eigencloud.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf

[5] LlamaRisk, “Beyond Shared Security: The Evolving Role of Restaking in DeFi.” https://www.llamarisk.com/research/restaking-in-defi

[6] BlockSec, “Examining EigenLayer and Restaking from the Security Perspective.” https://blocksec.com/blog/examining-eigenlayer-and-restaking-from-the-security-perspective

[7] EigenLayer Foundation, “ELIP-006: Redistributable Slashing.” https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-006.md

[8] N. Durvasula and T. Roughgarden, “Robust Restaking Networks,” ITCS 2025. https://arxiv.org/abs/2407.21785

[9] Anonymous authors, “On Sybil-proofness in Restaking Networks.” https://arxiv.org/abs/2509.18338

[10] Ethereum, “Proof-of-Stake Rewards and Penalties.” https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/