Skip to content
Web3 Academy

Restaking

Reading depth

Each view includes the earlier layers; the complete engineer or auditor page is shown by default.

Restaking subjects staked or staking-derived assets to additional service commitments in exchange for possible payments and additional loss conditions.

Stacked bars category cue

Restaking assigns existing stake or a staking-derived position to additional service commitments, payments, and loss conditions.

Why it exists

Section titled “Why it exists”

New services can be expensive to secure with a new token and operator set. Restaking lets them request economic commitments from existing stakers and operators, while those participants seek payment for extra software, availability, computation, data, or validation duties.

Traditional-finance analogy

Section titled “Traditional-finance analogy”

Re-pledging bonded capital to support additional guarantees is a useful analogy. One operator can run several independent services with different code, evidence, governance, payment, and slashing rules. Reusing stake does not copy base-chain consensus guarantees and can create correlated operational and loss paths.

Layered balance-sheet and claim view

Section titled “Layered balance-sheet and claim view”

The same asset value can appear in several accounting layers, but it is not new capital each time. Security claims must identify which allocated stake is actually slashable for which service and under whose evidence and authority.

Actors, assets, and claims

Section titled “Actors, assets, and claims”

The restaker owns or supplies accepted stake. A service operator receives delegation and runs base and additional software. Each additional service defines duties and reward terms. The restaking protocol records delegation, allocation, opt-in, rewards, slashes, undelegation, and withdrawals. Slashing, governance, or dispute authorities can differ across services.

Native stake or an accepted staking claim is the economic asset. An allocated restaking position, service reward, and queued undelegation or withdrawal are claims whose value depends on both base and additional layers.

Step-by-step mechanism

Section titled “Step-by-step mechanism”
  1. Deposit or register eligible native stake or a supported staking-derived asset.
  2. Delegate to an operator without confusing delegation with transfer of economic ownership.
  3. Review an additional service’s duties, code, operator set, reward asset, allocated stake, slash conditions, and exit delay.
  4. Opt in and allocate only the intended amount under protocol constraints.
  5. Perform and verify service tasks; accrue payments from the named service or incentive source.
  6. Submit and adjudicate any fault evidence through the exact authorized path.
  7. Apply rewards or slashes, then undelegate and withdraw after all stated delays and pending obligations.

For a common reporting asset and time window:

netRestakingReturn
= baseStakingReturn
  + servicePayments
  - operatorCosts
  - protocolFees
  - penalties
  - slashingLosses

Do not add advertised rates across tokens, horizons, vesting conditions, or unallocated stake without explicit conversions and weighting.

Flow and risk propagation

Section titled “Flow and risk propagation”

Capital flow moves base stake, service rewards, operator and protocol fees, penalties, and withdrawals. Claim flow records delegation, allocation, rewards, queued exits, and any staking-derived token. Information flow carries service tasks, evidence, operator-set state, allocations, exchange rates, and reward roots. Control flow includes operator opt-in, service governance, slashing authority, upgrades, and dispute handling.

Return flow carries base-network rewards plus service-customer fees, issuance, or incentives through operator and protocol deductions to the allocated position. Risk flow can correlate across services that share an operator, client, cloud, key, oracle, bridge, or restaking contract. A service-specific allocation may limit direct slash scope without eliminating price contagion, operator downtime, liquidity stress, or governance correlation elsewhere.

Return source and loss allocation

Section titled “Return source and loss allocation”

Base staking return retains its base-network payers. Additional return must come from service customers, fees, token issuance, or incentives; merely labeling stake “restaked” creates no cash flow. Loss begins with the allocated position under valid service or base rules, then reaches delegators, claim tokens, pools, and downstream collateral according to their accounting and legal boundaries.

Engineer or auditor lens

Section titled “Engineer or auditor lens”

Test operator registration, delegation ownership, allocation conservation, exclusive versus reusable stake, opt-in signatures, pending deallocation, service and operator-set identity, reward roots, duplicate claims, evidence authorization, slash bounds, upgrade and pause powers, undelegation delays, withdrawal races, native and token strategy accounting, and cumulative maximum loss across services. A service’s security property is not inherited merely because Ethereum stake appears in its accounting.

EigenLayer’s core-contract repository documents one current implementation connecting restakers, operators, and services through reward and penalty commitments. Its deployed contracts, asset support, allocation model, and reward terms are protocol-specific and should be reviewed at use time. The repository documentation was reviewed 2026-08-10.

Common misunderstandings

Section titled “Common misunderstandings”
  • “Restaking creates more security from the same capital for free.” It adds commitments and may improve economic deterrence, but also adds duties, evidence, contracts, control, and correlated risk.
  • “More rewards come from restaking itself.” A service, protocol, customer, issuance rule, or incentive budget must pay.
  • “Isolated slash allocation eliminates contagion.” It can bound direct protocol loss while shared operators, liquidity, prices, claims, and governance still connect systems.

Revisit slashing and distinguish direct stake from liquid-staking claims.

Machine-readable model

Key equations

Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.

  1. Equation 1

    Plain-text equation: netRestakingReturn = baseStakingReturn + servicePayments - operatorCosts - protocolFees - penalties - slashingLosses

Assurance contract

Security properties

These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.

Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.

  1. SP-01Desired · not evaluated

    Every service opt-in names the operator set, allocated stake, duties, reward terms, slashing conditions, authority, and exit delay

  2. SP-02Desired · not evaluated

    A service cannot slash stake outside its valid allocation or reuse the same exclusive allocation contrary to protocol rules

  3. SP-03Desired · not evaluated

    Delegation, allocation, reward, slash, undelegation, and withdrawal state transitions reconcile across base and additional layers

  4. SP-04Desired · not evaluated

    User interfaces preserve gross base stake, each service exposure, cumulative maximum loss, fees, and correlated dependencies rather than showing only aggregate yield

Knowledge check

Quiz

Answer in your own words, then open the model answer.

What problem does Restaking exist to address?

Model answer

Restaking lets new services obtain economic commitments from existing stake while operators and delegators seek compensation for extra work and slashable exposure.