Restaking and shared security

What restaking sells

A new decentralized service, whether an oracle network, a bridge verifier, a data availability layer or a coprocessor, needs operators who lose money if they misbehave. Bootstrapping that with a new token is expensive and circular: the token’s value is the security, and the security is what gives the token value. Restaking offers another route. Operators who already hold slashable stake agree to additional conditions set by the new service, and the service pays them for it.

The product is economic security: a credible promise that a specific amount of capital will be slashed, destroyed or redistributed, if specific rules are broken. Everything interesting about restaking design is in the words credible, specific and amount. This guide assumes you know how liquid staking tokens and Ethereum staking work.

EigenLayer’s architecture

EigenLayer, the restaking protocol from Eigen Labs, whose wider platform now carries the EigenCloud brand, has four roles: stakers deposit assets (liquid staking tokens, native ETH through EigenPods that point beacon chain withdrawal credentials at the protocol, EIGEN and other tokens); operators run the software; AVSs (the services) define tasks, rewards and slashing conditions; and stakers delegate to operators, inheriting whatever risk those operators accept.

For almost two years after deposits opened, restaked stake could not actually be slashed. Services were secured by the promise of future slashing, which is worth remembering whenever a system is described as having economic security before its penalties are live. At launch, redistribution excluded native ETH and EIGEN; other assets, including liquid staking tokens and stablecoins, were eligible.

Slashing with unique stake allocation

The earlier EigenLayer design made an operator’s entire delegated stake slashable by every AVS it served, which required a global veto committee to contain the damage and kept AVS onboarding permissioned. The slashing design specified in ELIP-002 replaces that with unique stake. An AVS groups operators into operator sets, and each operator allocates an explicit share of its delegated stake, per asset, to each set it joins. No two sets can slash the same stake.

# ELIP-002 unique stake accounting, one operator, one strategy (illustrative)
delegated      = 100_000          # ETH delegated to the operator
total_mag      = 1.00             # INITIAL_TOTAL_MAGNITUDE is 1e18; scaled to 1 here
alloc          = {"A": 0.30, "B": 0.20}   # 50% left unallocated, not slashable

slashable = {s: delegated * m / total_mag for s, m in alloc.items()}
# {"A": 30000.0, "B": 20000.0}

# AVS A slashes half of its own allocation
cut        = alloc["A"] * 0.5     # 0.15 of magnitude
alloc["A"] -= cut
total_mag  -= cut                 # total magnitude only ever decreases
delegated  -= 100_000 * cut       # 15,000 ETH leaves the operator's delegation

slashable = {s: delegated * m / total_mag for s, m in alloc.items()}
# {"A": 15000.0, "B": 20000.0}   B's slashable stake did not move

The worked example is the point of the design. AVS A slashed its own allocation in half, 15,000 ETH left the operator, and AVS B’s slashable stake stayed at exactly 20,000 ETH. Unallocated stake, half of the original delegation, was never at risk from either. The delays around allocation are what make the promise credible:

These are governance set values as specified in ELIP-002; check the deployed contracts before depending on them. With redistribution, an operator set created as redistributable names a recipient for slashed funds, which enables lending and insurance style cover and also creates a new incentive: whoever controls the slashing logic of a redistributable set can pay themselves. The protocol makes a set redistributable only at creation, so stakers can see it before they allocate.

Symbiotic and other designs

Symbiotic deployed its first contracts on June 11, 2024 and went feature complete with slashing on mainnet on January 28, 2025, with non upgradeable core contracts. Its unit is the vault: a container for a single collateral token whose curator decides how stake is delegated across networks and operators and which slashing flow applies. Networks request slashes through their own middleware; the vault’s slasher checks the request against the stake that was captured at a point in time, which stays slashable for one vault epoch.

The veto design is worth dwelling on. Symbiotic’s VetoSlasher gives configured resolvers a window to block a slashing request, and new resolvers only take effect after a delay measured in vault epochs so depositors can exit first. That is an explicit admission that many faults cannot be proven purely on chain, and that someone has to adjudicate them. Every restaking system needs an answer to that question; the answers differ in who adjudicates and how quickly. In July 2026 Symbiotic also launched a second version of its core, extending vaults toward insurance, credit and tokenized asset use cases. Other restaking and shared security protocols exist on Ethereum and other chains, and the same questions apply to each.

Cost of corruption versus profit from corruption

The basic safety condition for any stake secured service: attacking must cost more than it pays. For a service that accepts results signed by a fraction q of its operators’ stake, and slashes attacking stake in full:

That sum is the whole difficulty of shared security. Take illustrative numbers: an operator set with $900 million of slashable stake secures three services, each accepting a two thirds quorum, so corrupting any of them costs $600 million.

Each service looks overcollateralized on its own dashboard. Together they are not. Unique stake allocation fixes the accounting for stake allocated to different operator sets, but the reasoning applies to any stake an attacker can use against several services simultaneously, and profit from corruption is hard to measure: it includes everything downstream that trusts the service, such as the lending markets that read the oracle.

Durvasula and Roughgarden give the cleanest result on how failures spread (Robust Restaking Networks, 2024). They characterize robustness by the buffer between attack costs and attack profits. For example, if costs always exceed profits by 10%, a sudden loss of 0.1% of total stake, say from a software bug, cannot cascade into a loss of more than 1.1% of total stake. Without a buffer, one slash lowers the cost of attacking the next service, which can make it profitable, and so on down the chain.

Correlated slashing

Slashing risk in restaking is correlated by construction, and the correlations come from several directions at once.

The last row is the one most often underweighted. Restakers are exposed not only to operator misbehavior but to the correctness of every AVS’s slashing contract their operator opts into, which puts audit quality for code you never chose squarely in your risk.

Liquid restaking tokens and leverage loops

Liquid restaking tokens (LRTs) wrap a restaked position in a transferable token: ETH is staked, the staking token is restaked and delegated by the LRT protocol, and the user holds a token that accrues whatever the basket earns. LRTs are then used as collateral, which invites the familiar loop: deposit the LRT, borrow ETH, buy more LRT, deposit again.

With illustrative numbers: 100 ETH of equity, borrowing 90% of each deposit, five loops. Exposure is 468.6 ETH against 368.6 ETH of debt, 4.69 times leverage. If the LRT earns 3.0% and ETH borrowing costs 2.5%, the position earns about 4.8% on equity instead of 3.0%. With a 93% liquidation threshold it starts at a health factor of 1.18, and a 15.4% fall in the LRT’s price against ETH liquidates it. Those rates are for illustration only.

The dangerous part is that an LRT can lose 15% against ETH without anything being wrong with the underlying stake. Exits stack delays: the LRT protocol’s own queue, EigenLayer’s 14 day withdrawal delay, and the beacon chain exit queue. While redemption takes weeks, the only fast exit is selling on a DEX, and thin liquidity can push the market price far below the backing. Whether a lending market values the LRT at its exchange rate or at its market price then decides who gets liquidated, which is an oracle design choice with direct consequences, covered in lending design. And the same ETH now appears in the staking protocol’s TVL, the restaking protocol’s TVL, the LRT’s TVL and the lending market’s TVL, which is why aggregated TVL overstates the capital actually present.

Shared security elsewhere

Restaking is one way to share security. Two older designs make useful comparisons:

The contrast is instructive. Interchain Security and Polkadot share security by running the same validators with protocol defined faults, which keeps punishments objective and limits flexibility. Restaking lets each service define its own faults, which is flexible and pushes the hard problem, deciding what counts as a fault and proving it, onto every service separately. See the Cosmos and Polkadot network pages for the chains themselves.

Evaluating a restaking position or a service

1. Find the slashing conditions and read them

   Which faults are slashable, who can trigger a slash, is there a veto or dispute window, and is the set redistributable? A service with no live slashing is secured by reputation, whatever its TVL.

2. Map the operator’s allocations

   Which operator sets or networks does your stake back, with what share, and can the operator add more without your consent? Check the delays that give you time to leave.

3. Sum the profit from corruption

   For the services your stake secures, estimate what an attacker gains by breaking them together, including downstream protocols that trust them, and compare it with the slashable stake behind them.

4. Price the exit

   Add up every queue between you and ETH, and look at DEX depth for the LRT if you hold one. If the fast exit is a market sale, the market price is your real collateral value.

Common questions

Where to go next