Restaking in EigenLayer: AVS, operators, and a second slashing layer
Restaking is a voluntary extension of staking rules: already staked ETH (or LST) is additionally delegated in EigenLayer so that the same collateral secures multiple services.
The key mistake is reducing restaking to “extra yield.” In the EigenLayer model, not only a source of payments is added, but also a separate punishment layer: slashing conditions are defined not only by Ethereum, but also by external services.
EigenLayer connects Ethereum stake to external services through AVS: the service pays operators for enforcing rules and receives a slashing mechanism as a cryptoeconomic guarantee.
In one sentence: restaking in EigenLayer is the connection of already staked ETH (or LST) to external services (AVS) through operators, so that the collateral becomes slashable under their rules.
Mini-mechanics: the restaker delegates collateral to an operator → the operator serves the selected AVS → the AVS pays rewards → if rules are violated, the AVS initiates slashing under a predefined policy.
Below are the roles of restaker / operator / AVS, the architecture of collateral connection (native ETH and LST), payment sources (AVS payments), and risk sources (AVS slashing policy, operator choice, correlated failures).
Restaking: makes ETH “reusable” collateral: one stake secures Ethereum and the selected AVS, while the price of those payments is AVS slashing rules and dependence on operators.
Material updated → stronger focus on EigenLayer architecture (AVS/operators) and the second slashing layer.
- Overlaps separated → “what restaking is” moved into the angle of the “market of responsibility / price of error.”
- RSFi scenarios clarified → the LRT discount is tied to AVS risk and correlated events.
How the EigenLayer protocol works in the Ethereum ecosystem
EigenLayer is a smart contract protocol on Ethereum that makes already staked ETH (or LST) slashable under the rules of external services (AVS) through delegation to operators.
Base flow: collateral is connected in EigenLayer → delegated to an operator → the operator serves selected AVS → the AVS pays for correct operation → if AVS rules are violated, a penalty (slashing) is applied to the allocated collateral.
EigenLayer roles: restaker / operator / AVS
| Role | What it provides | What it does | Where risk arises |
|---|---|---|---|
| Restaker | Collateral (ETH/LST) delegated to an operator | Choice of operator and set of AVS to support | Slashing under AVS rules + dependence on operator behavior |
| Operator | Infrastructure and operation of the AVS stack | Signatures/proofs/availability under AVS requirements | Penalties for violating AVS rules; operational error |
| AVS | Validation rules and slashing/reward policy | Verification of operator actions (under its own logic) | Rule design errors, bugs in contracts/verification |
Collateral connection: native ETH and LST
- Native ETH: the validator links withdrawal credentials to the EigenPod address so the stake is accounted for by EigenLayer and can fall under AVS rules.
- LST: LST are deposited into EigenLayer strategies and then delegated to an operator without running a personal node.
Slashing in restaking: AVS rules and allocated collateral
- Conditions are set by the AVS: violations are defined at the service level (for example, invalid signatures, failure to complete tasks, violation of availability requirements).
- The penalty is tied to allocated collateral: punishment is applied to the portion of delegated stake that participates in serving a specific AVS under its rules.
Practical risk filter: the risk profile is defined by the operator’s AVS set, their slashing policy, and the operator’s ability to serve that set without losing uptime and execution quality.
EigenLayer connects delegated stake and external services through operators: the AVS pays for rule execution, and a rule violation can lead to slashing of allocated collateral.
Practical examples of EigenLayer and restaking use
AVS (Actively Validated Services) use restaking as a responsibility mechanism: the operator is paid for complying with service rules, and violating those rules can lead to slashing of allocated collateral on Ethereum.
AVS template: the service defines an obligation → defines verification (how the violation is recorded) → defines a penalty (size and conditions) → the operator answers with delegated collateral.
Data Availability (EigenDA and similar systems)
DA services answer a rollup ecosystem question: are the data needed to verify state and reconstruct history actually available.
- What the operator commits to: store data fragments (chunks — parts of a data set) and provide them under protocol rules within defined time windows.
- What counts as a violation: data unavailability, refusal to serve data, confirmation of availability without actual delivery.
- Why restaking is needed here: data availability becomes a slashable obligation, not a provider promise.
- What the market gets: the DA layer scales separately from L1, reducing load on Ethereum without “trusted” storage.
Restaking turns DA into the
Oracles and data services
In oracles, the value of restaking lies in the “price of error”: incorrect data triggers liquidations and changes risk parameters, so an economic penalty is needed for distorting the feed.
- What the operator commits to: publish correct data (for example, price) in the agreed format, frequency, and source set.
- What counts as a violation: deliberate substitution, coordinated manipulation, systematic delays in updates (stale data — “outdated” data).
- Why restaking is needed here: an attack on data must be more expensive than its potential profit, otherwise incentives break.
- How responsibility is usually “embedded”: the AVS sets participation and penalty rules; weight/quotas may account for delegated stake, but risk is defined by the slashing conditions of the specific service.
Restaking increases the
Restaked rollups and L2 components
Part of L2 infrastructure can be moved into an AVS and tied to the slashable responsibility of operators instead of building its own “validator economy” (a separate set of participants and security incentives).
- What the operator commits to: perform L2 component rules (ordering, publication, agreed checks) under defined conditions.
- What counts as a violation: conflicting state claims, censorship, refusal to serve, violation of service protocol guarantees.
- Why restaking is needed here: slashable responsibility reduces dependence on the “good faith” of a limited operator set.
- What the market gets: faster service launch and fewer incentives to build a separate token only for security.
An L2 component can receive
Computation and verifiable results
In computational AVS, the task is framed as a contract for a result: payment is made for protocol-compliant execution, while sabotage becomes a slashable risk.
- What the operator commits to: execute the computation/procedure and provide proof of the result under service rules.
- What counts as a violation: result substitution, non-execution, failure to comply with verification/proof format.
- Why restaking is needed here: “honest execution” is moved from trust in the provider to economic responsibility.
- What the market gets: computation infrastructure with a controlled price of error and slashable participant obligations.
Restaking makes execution quality a
AVS categories: bridges and cross-chain messengers (bridged vs native stablecoins), ZK modules (zero-knowledge proof verification), DePIN networks (decentralized physical infrastructure), and coordination services where the economic responsibility of operators for rule violations matters.
Criterion for use: restaking is used where the price of error must be high: the AVS pays for rule execution; rule violations make the operators’ allocated stake slashable.
Restaking as a market of responsibility: security budget and the price of error
In EigenLayer, payments appear not “for the mere fact of staking,” but for taking on additional obligations: the AVS buys slashable execution correctness, while risk is defined by slashing policy and operational complexity.
Short framing: security budget means “how much an attack or sabotage costs.” Restaking raises the security budget not through promises, but through the chain “verifiable rule → formal violation trigger → penalty to allocated collateral.”
-
The AVS buys responsibility, not “liquidity.”
- The point of the deal: the service pays for requirement execution (signatures, availability, correct results), while violation becomes measurable damage through slashing.
- What is fixed: the “price of error” is determined by AVS rules, not by provider reputation.
-
Restaking addresses the early weakness of new protocols.
- The problem: a protocol’s own validator set is small at launch, so the cost of attack is often low.
- Practical effect: the service gains access to a larger pool of delegated stake without issuing a separate token “for security.”
-
Yield is payment for risk and execution complexity.
- Payment source: AVS payments to operators (taking into account fees and requirements).
- Price of payment: the probability of slashing rises with the number of AVS, stack complexity, and infrastructure correlations.
Market rule: restaking is a market of shared security where “cost” is defined by slashing policy, damage caps, and quality of operational execution, not by headline percentages.
EigenLayer monetizes security as a service: the AVS pays for rules and slashable guarantees, while the stake receives an additional payment flow together with an additional slashing layer.
Advantages of EigenLayer restaking for validators and ETH holders
Restaking adds a second responsibility layer to ETH staking: payments come from AVS, while risk is defined by their slashing rules and operator quality.
Logic of advantages: additional payments appear only where stake accepts additional responsibility. In restaking, responsibility is defined by the slashing policy of specific AVS and the quality of operator execution.
Advantages of restaking: payment source and risk price
-
Payments on top of base staking
Source: payment from AVS for serving service rules (through the operator and its fee).
Price: slashing under AVS rules and dependence on operator operational reliability.
-
Diversification of payment flows
Source: the operator’s AVS set (different payment models and different requirements).
Price: risk overlap: one operator failure can affect several AVS at the same time.
-
Participation without a personal node through LST/LRT
Source: liquid structures (LST) and overlays (LRT) that combine base rewards and AVS payments in one asset.
Price: additional risk layers: smart contracts, depegs/discounts, exit liquidity, LRT protocol conditions.
-
Flexibility in distributing responsibility
Source: delegation to an operator and AVS selection determine which part of the stake falls under which rules.
Price: risk limitation works only through formal caps and strategy architecture, not through intentions.
-
Demand for ETH stake as a “security service”
Source: AVS buy security from the Ethereum staking market instead of issuing a token for validators.
Price: security becomes a competitive market: payment conditions, AVS sets, and operator requirements change.
Example (without numbers): the base reward for Ethereum staking remains, and on top of it payments from one or several AVS may appear. The outcome is defined by two parameters: (1) the amount of AVS payments; (2) the risk profile — slashing policy and the probability of operational errors at the selected operator.
Restaking increases capital efficiency (one collateral supports several payment and responsibility layers) through AVS payments, but expands the slashing layer and makes risk management a mandatory part of the model.
Restaking risks: slashing, correlated errors, and pressure on Ethereum
AVS payments are compensation for additional responsibility: external service penalty rules are added to Ethereum slashing, and correlated failures increase the probability of cascading scenarios.
Two penalty layers: Ethereum defines slashing for L1 consensus, while restaking adds slashing under AVS rules. Risk is defined by AVS slashing policy and operator operational reliability.
Slashing under AVS rules
The operator takes formal obligations to each AVS, and violating rules leads to a penalty on allocated collateral.
- Triggers: downtime, invalid signatures, incorrect data handling, conflicting actions, incompatibility after client updates.
- Damage scale: defined by AVS policy (conditions, caps, violation gradations) and by how much stake is actually serving that AVS.
- Limiters: AVS exposure caps, distribution across operators, refusal to use AVS with unclear slashing policy or high operational complexity.
Observation: the more AVS an operator serves, the more independent failure points exist, and the higher the probability of penalties during ordinary failures.
Correlated events and mass penalties
One shared cause can affect many operators at once, including honest participants.
- Triggers: a bug in AVS logic, disputed configuration, ambiguous rules, synchronized faulty updates across many operators.
- Damage scale: mass penalties cause simultaneous losses and intensify stake outflows from a service or protocol.
- Limiters: caps on maximum penalties, limits on stake share in one AVS, independent verification, insurance or compensation mechanisms (if provided by market design).
Observation: a shared bug or disputed AVS configuration can trigger mass penalties at one moment.
Weakening stake discipline under large off-L1 damage
A severe penalty at the AVS level can sharply reduce the validator’s economic “stake,” weakening the disciplining role of collateral.
- Triggers: deep slashing in one AVS or a series of penalties across several services during a shared operational problem.
- Damage scale: reduced collateral lowers the “price of error” for the participant and raises the tendency toward risky decisions.
- Limiters: localization of disputed cases inside the restaking layer, limits on penalty depth, service-level conflict resolution procedures, not Ethereum consensus-level procedures.
Observation: disputed and subjective slashing cases are critically important to keep inside the restaking layer.
Concentration around a large AVS and systemic pressure
Growth in the share of validators tied to one AVS raises the probability that a local conflict becomes systemic.
- Triggers: disputed penalties, critical failures, or contentious updates in a dominant AVS.
- Damage scale: a significant share of operators and delegated stake is affected, and “quiet” conflict resolution becomes harder.
- Limiters: diversification across AVS, concentration caps, conflict resolution procedures at the service or restaking-layer level, not at the Ethereum level.
Observation: high concentration around one AVS makes it harder to isolate conflicts without systemic effects.
Restaking adds risks absent in base ETH staking: AVS slashing, correlated failures, and conflict situations around rules. Exposure reduction usually relies on stake share caps, distribution across operators, and regular review of the AVS set and its slashing policy. A penalty can fully erase accumulated profit.
Condition for stability: restaking amplifies ETH staking risks through AVS slashing and correlated infrastructure events. Without exposure caps and a clear understanding of slashing policy, the model becomes a source of losses faster than a stable payment flow.
Restaking, LST, delegation, and LRT: term boundaries and risk points
Restaking adds a second layer of rules to stake — slashing under AVS policy. LST solves staking liquidity. Delegation defines the executor. LRT aggregates restaking strategies into one token and transfers AVS risk into price.
Term boundary: LST = token representation of stake; delegation = choice of operator/validator; restaking = connecting stake to AVS with a separate slashing policy; LRT = an overlay that aggregates restaking strategies into one token.
| Instrument | What is fixed | Where payments come from | What becomes risk |
|---|---|---|---|
| Delegation | Who executes network rules | L1 consensus rewards | Operational failures of the executor within L1 rules |
| LST | Stake share through a liquid token | Staking rewards + LST protocol mechanics | Smart contract risk, discount/depeg, exit liquidity |
| Restaking | Collateral becomes slashable under AVS rules | Payments from AVS (through operators) | AVS slashing, correlated failures, dependence on the operator’s AVS set |
| LRT | Package of strategies (LST + restaking) in one token | Staking rewards + AVS payments | Inherited AVS slashing, strategy/contract risks, discount as the price of AVS risk |
Practical assembly: the chain “staking → LST → restaking → LRT” adds layers: first liquidity (LST), then AVS responsibility (restaking), then strategy aggregation (LRT). Each next layer adds its own rules and its own failure points.
Role separation: delegation chooses the executor, LST provides liquidity, restaking adds a second slashing layer under AVS rules, and LRT transfers the AVS risk profile into token price.
Restaking in DeFi: RSFi, LRT, and the transfer of AVS risk into collateral price
Restaking creates the foundation for RSFi (restaking finance): LRT products, yield strategies, and slashing insurance schemes, but the key feature is the transfer of AVS risk and operator correlations into LRT price and collateral quality.
Key risk transmission channel: in RSFi, the state of restaking appears through LRT price. LRT discount to ETH reflects not only exit liquidity, but also a reassessment of the probability of AVS slashing and correlated infrastructure events; in lending, this most often appears through rising LTV and the start of liquidations.
-
LRT tokenizes a “portfolio of obligations.”
- Mechanics: base staking rewards are supplemented by AVS payments, and the strategy is tokenized into LRT.
- Risk composition: AVS slashing, operator risk, correlated failures across the AVS set, contract risk, and strategy-packaging risk.
-
LRT as collateral strengthens connected systemic scenarios.
- Scenario: LRT is used in lending, pools, or derivatives and remains tied to restaking risk.
- Consequence: the same economic stake simultaneously participates in Ethereum, AVS, and DeFi position layers.
-
LRT discount accelerates liquidations through collateral quality.
- Triggers: expectation of slashing, higher operational uncertainty among operators, concentration around a large AVS, disputed updates, or incidents in AVS.
- Transmission into DeFi: the discount worsens collateral, raises effective LTV, and accelerates liquidations in connected protocols.
-
Slashing insurance becomes a separate design layer.
- Mechanics: part of AVS payments is directed to an insurance pool or compensation reserve.
- Structure: conservative layers receive lower payments but have priority in compensation; aggressive layers accept higher risk.
Why this can become systemic risk: LRT price affects collateral across many protocols at once. When AVS risk is repriced, the LRT discount worsens collateral quality and accelerates liquidations, intensifying cascading sell-offs.
Scenario example: ETH → LST → restaking → LRT → use of LRT as collateral for a stablecoin loan. In this chain, the same stake simultaneously secures Ethereum, serves AVS, and supports a credit position, so LRT discount accelerates liquidation risk.
Source of cascades: RSFi is built around LRT and AVS payments, while the main channel of systemic effects is the transfer of AVS slashing expectations and correlated failures into collateral price and exit liquidity.
The future of restaking and shared security models
Restaking is moving toward a “shared security” format: projects connect to a market layer of responsibility (payments for rules and penalties) instead of building their own validator economy.
Main growth crossroads: the scale of restaking is defined by integration standards, slashing design, and incident localization procedures, not only by the number of new AVS.
| What changes | Why it is needed | What it reduces |
|---|---|---|
| Standardization of AVS interfaces and risk profiles | Comparability of conditions and lower “integration cost” of security | Fragmented integrations and errors caused by unique implementations |
| Formal rigor (audits, verification, post-mortems) | Access to large stake only for mature modules | Risk of critical bugs and unexplained “black boxes” |
| Engineering slashing (caps, gradations, clear triggers) | Controlled price of error and predictable damage | Mass penalties caused by rare or disputed events |
| Incident procedures (resolvers, arbitration, compensation) | Localization of conflicts inside the restaking layer | Transfer of disputes and pressure to the Ethereum base layer |
What will become “market norm” for security operators:
- AVS portfolio and exposure caps. Service set and formal limits on the share of stake under each slashing policy.
- Processes instead of promises. Update procedures, monitoring, response, testing, and incident logging.
- Transparency and reputation. Failure and slashing history, public reports, clear conflict and compensation rules (if provided).
- Correlation control. Accounting for common stack components and “one bug for all” risks during mass updates.
Transitional stage: the first large stress scenarios are almost inevitable (bugs, disputed penalties, correlated failures). Model resilience is defined by damage caps, transparent review procedures, and conflict localization mechanisms at the restaking level, not at the Ethereum consensus level.
Vector: if standardization succeeds, security can become an infrastructure service with cryptoeconomic guarantees, where “terms of responsibility” are read as transparently as tariffs and SLA in classical infrastructure services.
Success factor: the future of restaking is determined by the engineering of responsibility: AVS standardization, predictable slashing, and incident localization procedures without systemic cascades.
FAQ on restaking and the EigenLayer protocol
Short answers to frequent questions: what restaking and AVS are, whether 32 ETH is required, where payments come from, and where slashing risk actually appears.
What is restaking in simple terms?
What is AVS in the EigenLayer context?
Is 32 ETH required to participate in restaking?
What yield can restaking provide?
How does restaking differ from liquid staking (LST)?
Is capital loss possible because of restaking?
Could restaking weaken Ethereum’s own security?
Final summary: restaking, LST, delegation, and LRT
Restaking adds a second responsibility layer to ETH staking: stake becomes slashable under AVS rules. This creates a market of shared security and payments for infrastructure tasks, but expands the risk layer for stake and DeFi chains around LRT.
Summary in one line: EigenLayer connects ETH stake to external services and turns operator obligations to AVS into slashable responsibility through slashing of allocated collateral.
Where utility appears (what the market buys):
- Security as a service. AVS receive protection based on Ethereum stake without launching their own validator economy.
- Fast infrastructure launch. Protocols connect to a ready-made responsibility layer instead of building a “token for validators.”
- New primitives for DeFi. LRT and RSFi products tokenize payments and responsibility, but along with them, risks are also tokenized.
Where risk appears (what becomes the price of payments):
- AVS slashing. On top of Ethereum rules, separate slashing policies appear for each service.
- Correlated failures. Shared stack components and mass updates can lead to synchronized violations across many operators.
- Cascades through LRT price. LRT discount worsens collateral quality and accelerates liquidations in lending protocols.
Core of the model: restaking on EigenLayer is not “an extra percentage,” but a model with expanded responsibility. Stability depends on exposure caps, diversification across operators and AVS, and readiness for slashing and correlated failures.
Condition for becoming a standard: restaking will become established as an infrastructure standard if incidents are localized inside the restaking layer (damage caps, review procedures, reserves/compensation), and risk is assessed as strictly as smart contracts and collateral in DeFi.