Restaking Explained: What Gets Reused, and Where the Risk Stacks

An intermediate-level look at what actually gets reused when ETH is restaked, and how risk stacks across Ethereum, restaking protocols, LRTs, and downstream DeFi.

Restaking, explained in one paragraph

Restaking explained in the shortest useful form: restaking is an opt-in mechanism that uses economic value already connected to Ethereum staking as slashable backing for additional services outside Ethereum's base consensus. In return, participating stakers and operators may receive rewards from those services. No ETH is duplicated. What gets reused is the economic commitment behind staked ETH or an eligible token claim, and additional slashing conditions are attached to that value. The common shorthand that "the same ETH works twice" is directionally suggestive, but it is not a mechanism. To reason about restaking safely, it helps to think in terms of a chain: what is reused, who controls what, and where a loss can enter.

What gets reused, and what does not

Restaking is easiest to teach when the reused element is stated cleanly. What restaking reuses is the economic commitment attached to staked ETH or an eligible token claim, together with the withdrawal path that value already flows through. Restaking then adds another set of contracts, rules, operators, and slashing conditions on top of that value. It does not automatically pass Ethereum's finality, validator set, protocol governance, or social consensus to any external service. An AVS receives only the security arrangement it actually establishes.

That distinction sounds abstract, but it is the difference between a marketing headline and a mechanism. When a project says its network is "secured by billions of dollars of restaked ETH," the important question is not the total number. It is how much stake, allocated by which operators, is committed to the operator set that secures this specific service, and under what slashing conditions.

The four core roles: restaker, operator, operator set, and AVS

To read any restaking product with a straight face, four roles need to be clear. The restaker is the person or contract that supplies ETH, a liquid staking token, or another supported asset to the restaking protocol and delegates that balance to an operator. The operator runs off-chain software for services, receives delegated stake, joins operator sets, and allocates portions of delegated stake to specific tasks. The operator set is a group of operators assigned to a specific security role for an AVS. The AVS, or Autonomous Verifiable Service, is the external service that defines tasks, creates operator sets, distributes rewards, and may define slashing conditions.

There is one more piece worth naming: in current EigenLayer accounting, each operator has a total "magnitude" for a given strategy, and the sum of that operator's allocations across operator sets cannot exceed 100 percent of it. A "strategy" here is the protocol's accounting representation of an asset (native ETH, a specific LST, or a supported ERC-20). The magnitude is how much of that asset the operator has available to allocate. Two operator sets cannot claim slashing rights over the same slice of that magnitude at the same time. This is the accounting property that makes Unique Stake possible, and it is worth remembering because most explainers skip it.

A useful distinction lives in that structure. The operator does not have custody authority over the restaker's tokens. It cannot withdraw them. But it does have real risk authority. By allocating slices of delegated stake to operator sets, the operator is deciding which slashing conditions those slices are exposed to. Custody and risk authority are not the same thing, and most beginner explainers blur them. That blurring is worth calling out, because "the operator can't touch your funds" is often used as if it settles the safety question. It does not. The operator can still expose delegated value to slashing under rules chosen by an AVS the restaker never personally evaluated. Because staking, LSTs, smart contracts, and DeFi all sit under this structure, restaking is not a first step. Blockready places it after Ethereum proof of stake, staking routes, and DeFi basics for the same reason: without those layers, the mechanism reads as jargon.

Native, direct LST, and LRT-managed restaking

People say "restaking" for at least three different routes, and each involves a different set of actors. The first is native restaking, where the user operates an Ethereum validator, points the validator's withdrawal credentials at an EigenLayer-controlled contract path (typically through an EigenPod), and delegates the restaked balance to an operator. Native restaking keeps validator work with the same user, which reduces counterparty risk but requires competence to run a validator without downtime or slashing errors.

The second is direct LST restaking, where the user deposits an eligible liquid staking token, such as one representing a claim on pooled staked ETH, into a restaking strategy contract and delegates as before. This route is more accessible because the LST already handles validator operations, but it stacks two protocol dependencies before the restaking layer begins.

The third route is LRT-managed restaking, where a third-party protocol accepts ETH or LSTs, manages the underlying restaking positions on behalf of many users, and issues a liquid restaking token (LRT) as a claim on the managed position. LRT-managed restaking abstracts the most decisions away from the user, which is often described as a convenience feature. It is also where the largest number of hidden governance and portfolio-construction choices sit. Different LRT products can produce very different exposure profiles from the same starting ETH.

The three routes look similar on a homepage, but they differ in who controls the underlying position. In native restaking, the user still runs the validator. In direct LST restaking, an LST protocol runs the validators, and the restaker sits one layer up. In LRT-managed restaking, an additional manager selects operators, chooses which AVSs to allocate to, and decides how the pool is rebalanced. Each layer adds smart contract risk, governance dependencies, and a new place where redemption can slow down or fail. Reading a product's disclosures at the level of "which of these three routes is this" is a small habit that pays back most of the effort in comprehension.

What security an AVS actually receives

"Restaking gives new services Ethereum-level security" is one of the category's most repeated lines, and the one worth challenging first. An AVS does not inherit Ethereum's total staked ETH, its validator set, or its finality. It receives a security arrangement built from what it actually recruits: its participating operators, the amount and type of stake those operators have allocated to its operator sets, its own task-verification system, its slashing conditions, its governance and dispute process, and its reward design.

Some AVSs run proof-of-authority sets of pre-approved operators. Others are permissionless but still bounded by whichever operators join and how much magnitude they allocate. Slashing conditions can be objective (mechanically provable on-chain), subjective (decided by governance vote or a committee), or intersubjective (decided by a broader group agreeing on facts that are widely observable but not automatically verifiable). Each choice has different failure modes. Objective slashing is legible and predictable, but only works where fraud can be proven mechanically. Subjective slashing handles fuzzier cases but depends on governance staying honest under pressure. None of these is automatically safer. They are trade-offs, and the trade-off worth checking is which one an AVS uses and why.

Unique Stake and the modern slashing boundary

Older explainers, some of them recent, still describe restaking as if a single slice of stake could be slashed by every AVS it "supports." That is not accurate for current EigenLayer. Under Unique Stake, each portion of an operator's delegated magnitude is allocated exclusively to one operator set, and only the AVS that created that operator set can slash it. The sum of an operator's allocations across strategies cannot exceed 100 percent of that operator's magnitude, so two operator sets cannot slash the same slice.

That is a meaningful change from the original pooled-security framing, and it is one of the biggest reasons "one stake secures many services and could be slashed by every service" is now outdated for direct AVS-to-AVS overlap on the same allocation. It is worth remembering when reading older articles, because the concept did shift in a way that matters for how a beginner should evaluate the mechanism. It is also worth being careful about what Unique Stake does not solve. It bounds direct slashing overlap for a single allocation. It does not remove operator failure, contract risk, governance risk, LRT manager risk, or correlated failure modes across the wider stack.

LST vs LRT: a claim-stack comparison

Both LSTs and LRTs are liquid tokens. They are not the same product. An LST represents a claim on pooled staked ETH and its base staking yield. Its underlying value comes from Ethereum validator work: issuance, priority fees, and any MEV that flows through those validators. An LRT usually represents a claim on a managed restaking position that also includes AVS operator selection, AVS-paid rewards, protocol incentives, and (sometimes) additional token emissions. The LRT holder does not typically choose which operators or AVSs their pool uses. That decision sits with the LRT manager.

The most common LRT mistake is treating the extra yield as if it were free. It is not free. It is compensation for an expanded set of failure modes and a longer redemption chain. A market rush to sell an LRT can also open a discount to the underlying value before actual redemption completes, which behaves like a temporary loss for anyone exiting at that moment. Real LRT product disclosures acknowledge these risks. The educational task is to read them at that level, rather than as brand copy.

Two follow-up habits help. First, separate what the token is a claim on from how a market prices it. A well-run LRT can still trade below its underlying value during a stress event. Second, look at the redemption chain as a set of queues stacked end to end. Deallocation on the restaking side, LST redemption, and the Ethereum withdrawal queue can each take time. Together, they can produce a much longer exit than the "liquid" label implies.

The Restaking Risk Stack

The reason restaking rewards a claim-and-control view is that risk does not live in one place. It stacks across layers, and Unique Stake bounds one boundary without touching the others. The nine layers below are the categories worth naming before evaluating any restaking product.

Unique Stake changes the picture for layers four and five, because two operator sets cannot slash the same allocated slice. It does not change layers three, six, seven, eight, or nine. That is why a mechanism-first read of restaking is more protective than an APY read. Two positions that show the same headline yield can sit under very different combinations of these layers, and a difference at one layer can dominate the outcome.

Where restaking rewards come from

There is no single "restaking APY." The reward figure a restaker sees, or that an LRT displays, is usually a blend of several sources with very different quality signals. Ethereum base staking rewards come from issuance, priority fees, and MEV that flows through the validators used. AVS-specific rewards come from tokens the AVS distributes for its verification work, usually with AVS-defined logic and operator fees. Some AVSs may also distribute their own protocol tokens as short-term incentives to attract early operator and restaker participation. LRT holders receive whatever passes through the manager, minus manager fees. Additional DeFi incentives can layer on top when an LRT is used as collateral or supplied to a liquidity venue.

Reward-quality is worth thinking about component by component. An AVS reward tied to sustainable service revenue is not the same as an AVS reward funded by temporary token emissions, even if the two show as the same number on a dashboard. The former reflects paying customers who need the service. The latter reflects a subsidy that will eventually taper. Neither is automatically better, but conflating them makes forecasting real yield much harder. That is why a headline restaking APY is a poor place to start an evaluation: the number can hide five very different underlying answers.

Frequently asked questions

Where restaking fits in a structured learning path

Restaking is not a first crypto concept, and treating it as one usually leaves readers with a slogan instead of a mechanism. It sits after Ethereum proof of stake, staking routes, LSTs, smart contracts, and basic DeFi. That order is deliberate: an LRT built on an LST that is restaked to an AVS and posted as DeFi collateral touches every one of those layers. Blockready teaches restaking in that sequence rather than as a standalone yield topic. If any of the vocabulary in this article is new, such as AVS, operator set, magnitude, LST, LRT, Unique Stake, or EigenPod, the crypto glossary is the fastest way to fill those gaps before returning to the mechanism.