Restaking and EigenLayer
The previous page was about carving up one job — building a block — so no single party could quietly abuse it. This page is about the opposite move: taking one bond that already secures Ethereum consensus and asking it to secure more — other services, with their own rules, sharing the same capital.
Every earlier consensus page rested on one hard fact: a validator posted 32 ETH as a bond, and that bond can be slashed for provable misbehaviour. Restaking asks a deceptively simple follow-up question: that bonded ETH is sitting there, economically committed, slashable — could it also back the honesty of things Ethereum consensus itself never promises to secure? EigenLayer is the best-known system built to answer “yes.” This page explains the mechanism, what it unlocks, and the argument — still very much open, as of 2024 — over whether reusing one security budget across many systems is clever leverage or a way to wire unrelated failures together. Treat everything here as young and provisional: none of it is part of Ethereum consensus, and the safety claims have not had decades to be tested.
First, recall what a stake secures
Section titled “First, recall what a stake secures”Before restaking makes sense, hold two facts from the consensus part firmly in view.
- A stake is a bond, not a fee. The 32 ETH a validator posts is not spent — it is locked and slashable. Its whole security value is that misbehaviour can destroy it. Take away the destroy-ability and the bond means nothing.
- Ethereum consensus slashes only two, narrow, provable offences — double block proposal and conflicting (double/surround) attestation votes. That narrowness is deliberate: the protocol punishes only what it can prove mechanically from signatures, so no honest operator running correct software can be slashed.
So a staked validator carries a bond that Ethereum uses to enforce exactly two consensus rules. The capital is committed; the slashing surface it is exposed to is tiny. Restaking is the observation that the same committed capital could be made slashable under additional rules, for the benefit of additional systems.
Plain staking Restaking ───────────────────────────── ───────────────────────────── 32 ETH bonded same 32 ETH bonded │ │ ▼ ├─► secures Ethereum consensus secures Ethereum consensus │ (double-sign → slashed) (double-sign → slashed) │ ├─► ALSO secures Service A │ (break A's rule → slashed) │ └─► ALSO secures Service B (break B's rule → slashed)What restaking is
Section titled “What restaking is”Restaking is opting your staked ETH into securing extra services beyond Ethereum consensus, by agreeing that the same capital can be slashed under new, additional conditions those services define.
Read that carefully, because two words carry the whole idea:
- Additional. You keep doing your Ethereum validator job, exposed to Ethereum’s slashing, earning Ethereum’s rewards. Restaking layers more obligations on top — it does not replace consensus duties, it stacks alongside them.
- Slashable. The service you opt into securing is not buying a promise or a subscription. It is buying the right to destroy your stake if you break its rules. That is the only thing that makes the security real. A service secured by capital that can’t be slashed is secured by nothing — it’s the bond argument from staking, applied one layer out.
The reason anyone would accept extra slashing risk is the mirror image: extra rewards. The services paying for security pay their restakers for it. So restaking is a trade — you rent out your bond’s trustworthiness to another system, accepting that system’s slashing conditions, in exchange for a yield on top of your staking yield.
Note what restaking is not. It is not the protocol lending your ETH out, and it is not fractional-reserve leverage in the “same dollar promised to two people” sense. The ETH stays bonded and staked the whole time; what is being reused is not the money but the credible threat of losing it. One bond, exposed to several independent slashing rulebooks at once.
The EigenLayer model: restakers, operators, and AVSs
Section titled “The EigenLayer model: restakers, operators, and AVSs”EigenLayer is a set of Ethereum smart contracts that turns the abstract idea above into concrete roles. There are three, and keeping them straight is most of understanding the system.
RESTAKERS OPERATORS AVSs (supply security) (run the software) (consume security) ─────────────── ───────────────── ───────────────── have staked ETH register with EigenLayer an Actively Validated (or an LST); opt it and take on the actual Service: a data- into EigenLayer; duties of the AVSs they availability layer, DELEGATE to an serve; run the AVS's oracle, bridge, operator node software sequencer, etc. │ ▲ │ ▲ │ delegate stake │ │ serve │ └──────────────────────────┘ └────────────────────────┘ stake backs ──► operator's work ──► for the AVS which is slashable if the operator breaks the AVS's rulesRestakers — the capital
Section titled “Restakers — the capital”A restaker is someone who has staked ETH (or holds a liquid-staking token representing staked ETH) and chooses to restake it: deposit it into EigenLayer’s contracts and thereby make it available to secure additional services. Most restakers do not run any service software themselves. Instead they delegate their restaked stake to an operator, much as a small ETH holder delegates to a staking pool — the capital comes from the restaker, the work is done by someone else.
There are two flavours worth naming. Native restaking points a validator’s withdrawal credentials at EigenLayer so the actual 32-ETH validator bond is what backs the extra services. Liquid restaking deposits a liquid-staking token (a tradeable claim on staked ETH) instead. The distinction matters for exactly what is at risk, but the role is the same: supply slashable economic weight.
Operators — the labour
Section titled “Operators — the labour”An operator registers with EigenLayer and does the real work. When an AVS needs validators — nodes that watch, sign, attest, or compute on its behalf — operators are the parties that actually run that AVS’s software and perform its duties. Restakers delegate their stake to an operator; the operator’s honest performance is backed by that delegated stake. If the operator breaks an AVS’s rules, the delegated stake is what gets slashed.
This is a clean separation of capital from labour: a restaker with 100 ETH but no ops skills can back an operator with deep infrastructure but little capital of their own. It is also, unavoidably, a concentration surface — a handful of large operators can end up running duties backed by a very large pool of delegated stake, which is a theme the risk section returns to.
AVSs — the consumers
Section titled “AVSs — the consumers”An Actively Validated Service (AVS) is any system that needs its own crypto-economic security and, instead of bootstrapping a fresh token and validator set, borrows Ethereum’s restaked security. “Actively validated” is the key phrase: these are services that require a set of nodes to actively do something — watch data, attest to a fact, sign off on a bridge transfer, order transactions — and be punishable if they do it dishonestly.
An AVS defines three things:
- Duties — what its operators must do (e.g. “store this data and answer availability challenges”, “report this price honestly”, “sign only valid bridge withdrawals”).
- Slashing conditions — the provable offences that cost an operator (and the restakers behind it) their stake.
- Rewards — what it pays operators and restakers for the service.
In exchange, the AVS gets, on day one, a large pool of economic security it did not have to build. That last point is the entire commercial pitch, and it deserves its own section.
What it enables: security without a new token
Section titled “What it enables: security without a new token”To see why anyone builds an AVS instead of a normal chain, look at what launching a new crypto-economic service used to require.
Suppose you want to launch a new data-availability layer, an oracle network, or a cross-chain bridge. Each needs a set of independent nodes whose honesty is economically enforced — because each is only as trustworthy as the cost of corrupting its node set. Historically your only option was to launch your own token and your own validator set: mint a token, convince people to buy and stake it, and hope the market value of that staked token grows large enough that attacking your service costs more than it’s worth.
That path has a brutal chicken-and-egg problem.
The bootstrapping trap (own token + own validators) ──────────────────────────────────────────────────── service is only secure ──► if a lot of value is staked │ a lot of value is staked ──► if the token is worth a lot │ the token is worth a lot ──► if the service is trusted and used │ the service is trusted ──► if it is SECURE ──┐ │ └───────────── circular ────────┘
Day one, the service has a low-value token, thin stake, and therefore CHEAP-TO-ATTACK security — exactly when it can least afford it.A brand-new service is at its most vulnerable precisely when its own token is worth the least — the moment its economic security is thinnest is the moment it most needs to be strong. Many otherwise-good middleware ideas never cleared this hurdle.
Restaking offers a different starting point. Instead of bootstrapping fresh security, the AVS rents existing security — a slice of the large, already-liquid pool of restaked ETH. On day one it can be backed by a substantial economic bond, without minting a token, without recruiting a validator set from scratch, without the circular trap above. The kinds of services this suits are the “middleware” that sit around and beneath the base chain:
- Data-availability layers — nodes that guarantee rollup data was published so anyone can reconstruct state and challenge fraud.
- Oracle networks — nodes attesting to off-chain facts (prices, events) that on-chain contracts consume; recall from oracle manipulation how much rides on those feeds being honest.
- Bridges — nodes signing off on cross-chain transfers, historically one of the most-attacked components in all of crypto.
- Other middleware — fast-finality gadgets, decentralised sequencers, keeper networks, and coprocessors that need a punishable node set.
The core risk: one budget, many claims
Section titled “The core risk: one budget, many claims”Now the hard part, and the reason the base layer does not endorse any of this. Restaking’s headline benefit — reuse one security budget across many services — is, viewed from a slightly different angle, its headline danger.
Correlated and cascading slashing
Section titled “Correlated and cascading slashing”Ethereum’s own slashing was carefully designed so that the punishment for a fault scales with how correlated it is — an isolated mistake is forgiven cheaply, a coordinated one is punished near-totally (the correlation penalty). Restaking introduces a new axis of correlation the base layer never signed up for: the same stake is exposed to many independent slashing rulebooks at once.
One operator's stake backs THREE AVSs at once:
┌───────── restaker stake (one bond) ─────────┐ │ │ AVS-A slash rule AVS-B slash rule AVS-C slash rule │ │ │ a bug in A's a bug in B's a bug in C's slashing logic ──► can burn the same bond that A and C rely onTwo failure shapes fall out of this:
- A buggy or adversarial AVS can slash stake that other services were counting on. If AVS-B’s slashing conditions are poorly designed — or maliciously designed — a fault there can destroy a bond that AVS-A and AVS-C also depend on. The services did not fail; their shared collateral was drained by someone else’s rules.
- Cascading slashing. If a large, widely-delegated operator gets slashed on one AVS, the loss hits every restaker behind it and every service they back simultaneously. A single event ripples across systems that have no relationship to each other except that they leaned on the same capital — the crypto-economic analogue of a shared dependency taking down unrelated apps.
Concentration and over-leverage
Section titled “Concentration and over-leverage”Two further pressures compound it. First, concentration: delegation naturally pools around a few large operators (better uptime, better returns), so a small number of parties can end up running duties for many AVSs on behalf of an enormous stake — a fat target, and a single point whose failure is maximally correlated. Second, over-commitment of one budget: the more services one bond promises to secure, the smaller the real security each one actually enjoys if a bad event forces the stake to answer to several at once. Promising the same collateral to enough claimants is how a nominally large security budget becomes thin exactly when everyone needs it.
Why the base layer stays out of it
Section titled “Why the base layer stays out of it”This is the crux of the systemic-risk debate. Ethereum consensus is deliberately conservative about what its stake secures — two provable offences, no more — precisely so the meaning of “slashed” stays narrow, predictable, and un-gameable. Restaking, by design, widens that surface with rules Ethereum never reviewed and cannot vouch for. The fear voiced by protocol researchers is spillover: that a failure in some risky AVS could, through shared and correlated stake, put pressure back on the health of Ethereum’s own validator set — importing the risk of a hundred experimental services into the one system that is supposed to be maximally boring and safe.
That is why restaking lives outside Ethereum consensus, as an application built on top, not a protocol feature. The base layer neither blesses nor guarantees any AVS’s safety. Whether restaking’s leverage is a net good depends entirely on whether its slashing conditions are as careful, and its concentration as limited, as the base layer’s — and that is an open, empirical question, not a settled one.
The architect’s lens
Section titled “The architect’s lens”- Why does it exist? Because a staked bond is idle security capacity — capital already committed and slashable, but exposed to only two narrow consensus rules. Restaking exists to rent that latent trustworthiness out to other systems that need crypto-economic security but can’t easily bootstrap their own.
- What problem does it solve? The bootstrapping trap: a new middleware service (DA layer, oracle, bridge) is least secure exactly when its own token is worth least. Restaking lets it start life backed by a slice of a large existing pool of restaked ETH — real security from block one, with no new token or validator set.
- What are the trade-offs? You buy shared security by accepting shared risk: one bond exposed to many independent slashing rulebooks means correlated and cascading slashing, concentration around big operators, and the chance that a bad AVS drains stake other services relied on. Leverage on the way up is contagion on the way down.
- When should I avoid it? As a restaker, avoid stacking AVSs whose slashing conditions you can’t evaluate — extra yield is not worth a rulebook you don’t understand. As a service designer, avoid it when your security needs are modest enough for a simpler trust model, or when importing correlated systemic risk outweighs the bootstrapping win.
- What breaks if I remove it? Nothing in Ethereum consensus — restaking sits outside it, which is the whole point. What you lose is a shortcut: new services go back to the slow, circular grind of minting a token and growing their own stake before anyone can safely trust them.
Check your understanding
Section titled “Check your understanding”- Starting from what a plain 32-ETH stake secures, define restaking in one sentence. Which two words in the definition carry the entire idea, and why is “slashable” the load-bearing one?
- Name EigenLayer’s three roles and, for each, say whether it supplies security, does the work, or consumes security. How do restakers who don’t run software still participate?
- Explain the bootstrapping trap a brand-new service faces when it launches its own token and validator set. How does becoming an AVS on restaked ETH change its day-one security, and what does restaking pointedly not create?
- Give two distinct failure modes that arise from one bond backing many AVSs. Tie each back to the idea that restaking adds a new axis of correlation the base layer never endorsed.
- Why does Ethereum consensus keep restaking outside the protocol rather than adopting it as a feature? What is the “spillover” fear, and why should the mechanics and safety claims on this page be treated as provisional?
Show answers
- A plain 32-ETH stake is a bond that secures only Ethereum consensus, slashable for two narrow offences (double proposal, conflicting attestations). Restaking is opting that staked ETH into securing extra services beyond Ethereum consensus by making the same capital slashable under new, additional conditions those services define. The load-bearing words are additional (obligations stack on top of consensus duties, they don’t replace them) and slashable. “Slashable” is the crux because security is only real if the bond can actually be destroyed — a service backed by un-slashable capital is backed by nothing; the reuse is of the credible threat of loss, not the money itself.
- Restakers supply security — they contribute staked ETH (or an LST) and make it slashable for the AVSs. Operators do the work — they register and run the AVSs’ node software and perform their duties. AVSs (Actively Validated Services) consume security — they borrow the restaked bond to back their honesty. Restakers who don’t run software participate by delegating their restaked stake to an operator (like delegating to a staking pool): the capital is theirs, the labour is the operator’s, and their delegated stake is what gets slashed if the operator breaks a rule.
- The trap is circular: a new service is only secure if a lot of value is staked, which needs the token to be worth a lot, which needs the service to be trusted and used, which needs it to be secure — so on day one it has a low-value token, thin stake, and cheap-to-attack security, exactly when it can least afford it. As an AVS on restaked ETH, it instead rents a slice of a large existing pool, so it starts with a meaningful, proportional security budget from block one — no new token, no validator set built from scratch. What restaking does not create is new security: the same ETH backing many AVSs is the same ETH.
- (a) A buggy or adversarial AVS can slash stake other services relied on — a poorly- or maliciously-designed slashing condition in one AVS drains a bond that unrelated AVSs also depend on. (b) Cascading slashing — a large, widely-delegated operator slashed on one AVS transmits the loss to every restaker behind it and every service they back at once. Both stem from restaking adding a new axis of correlation: the same stake is simultaneously exposed to many independent slashing rulebooks Ethereum never reviewed, so a fault in one can propagate to systems that share nothing but that collateral.
- Ethereum keeps restaking outside the protocol because its own slashing is deliberately conservative — two provable offences — so “slashed” stays narrow, predictable, and un-gameable; restaking widens that surface with rules Ethereum never reviewed and can’t vouch for. The spillover fear is that a failure in some risky AVS could, through shared and correlated stake, put pressure back on Ethereum’s own validator set — importing the risk of many experimental services into the system that is supposed to be maximally safe. The claims are provisional because restaking is young (as of 2024): it hasn’t faced years of adversarial pressure or mass-slashing incidents the way base-layer slashing has, so the role structure is likely durable but the detailed mechanics and the risk verdict are not yet settled.