Staking commits assets to a proof-of-stake network's rules. Restaking makes those assets, or claims backed by them, support additional services with additional conditions. The original staking risks remain, while restaking can add service-specific slashing, operator decisions, contract dependencies and extra exit steps. Compare the actual allocation and withdrawal rules for one position; a higher advertised reward does not establish how much can be lost or when the underlying asset becomes available.
Start with the duty attached to the stake
For Ethereum, staking activates validators that propose blocks and attest to the chain. Ethereum's staking overview describes this consensus role. Restaking adds another job to the economic backing. A service might require an operator to perform computation or provide data, with rewards and penalties attached to that service's commitments.
That is different from compounding. Reinvesting a staking reward increases the amount exposed to the original arrangement. Restaking changes the obligations attached to the backing, even if its amount stays constant. Receiving several reward streams does not create several independent reserves.
Ordinary Ethereum penalties and Ethereum slashing also differ. Missed duties can reduce rewards or incur penalties; conflicting proposals or attestations can trigger slashing and forced removal. The Ethereum rewards and penalties documentation identifies those separate mechanisms. A restaked position can perform its Ethereum duties correctly while an additional service imposes a separate loss under its own rules. Use the penalties versus slashing comparison to classify the base-network event before tracing the added obligation.
Trace the claim before counting services
Start at the instrument you hold, then follow its backing and control relationships. An Ethereum validator and the operator running an additional service may be different entities. A familiar provider name at one layer does not identify who controls the next.
The original EigenLayer paper describes both native restaking through validator withdrawal credentials and restaking through liquid staking tokens. These are different dependency paths, not interchangeable deposit instructions. Its conceptual routes explain the mechanism; current contracts and service terms determine an actual position.
For a hypothetical LST restaker, read the following table as a dependency graph: each row's left-hand component depends on the component to its right. Services A and B are separate branches sharing the restaking operator and the original backing.
| Component | Depends on | What the connection means |
|---|---|---|
| Holder's restaking claim | Restaking contracts | Contracts account for deposits, delegation and exit |
| Restaking contracts | Deposited LST and selected operator | Asset accounting connects the backing to delegated duties |
| Deposited LST | Staking pool and its validators | The claim remains tied to staked ETH |
| Underlying validators | Ethereum consensus rules | Base rewards, penalties and slashing remain relevant |
| Selected operator | Service A and B operator sets | The operator takes on each set's additional duties |
| Service A allocation | A's task and slashing rules | A can impose the permitted service-specific loss |
| Service B allocation | B's task and slashing rules | B adds another conditional exposure |
This is one backing chain with branches. Do not report the LST, the restaking claim and the underlying ETH as three pools of capital. The staking ratio and liquid supply ledger shows how layered receipts can otherwise duplicate the same backing.
Native restaking removes the LST-pool node from this particular graph, but it still requires tracing withdrawal contracts, delegation and service conditions. If another provider issues a liquid restaking token representing the position, add that provider's contracts, accounting and redemption rules above the graph. The label on a transferable token cannot establish those relationships by itself.
Work through one allocation, without multiplying the collateral
The EigenLayer implementation discussed here uses its published v1.13.0 core-contract documentation, inspected on 28 October 2026. This scopes the example; a release tag alone does not verify a particular application's deployed contracts.
ELIP-002's Unique Stake design assigns slashable portions to individual operator sets. It therefore matters how much is allocated to each set. “The operator supports two services” does not mean each service can necessarily slash the entire deposit.
Consider an invented position with 100 ETH-equivalent units of LST backing delegated to one operator. Assume the operator is registered to both sets, each set accepts this LST strategy, and both allocations are already effective. Assume a stable one-to-one accounting conversion, no rewards, fees, rounding, base-network losses, deposits or reallocation. Treat the allocations as fixed portions of the starting backing. This is a simplified exposure ledger, not a reproduction of EigenLayer's complete share accounting.
| Allocation at the snapshot | Starting backing | Assumed slash of that allocation | Modeled loss |
|---|---|---|---|
| Service A operator set | 40 ETH-equivalent | 20% | 8 ETH-equivalent |
| Service B operator set | 35 ETH-equivalent | 10% | 3.5 ETH-equivalent |
| Not allocated to either service | 25 ETH-equivalent | None in this scenario | 0 |
| Total | 100 ETH-equivalent | Separate conditions | 11.5 ETH-equivalent |
First, the allocations reconcile: 40 + 35 + 25 = 100. A's assumed loss is 40 × 0.20 = 8, leaving 92 units of backing. B's separately fixed allocation loses 35 × 0.10 = 3.5. After both modeled events, the remainder is 100 − 8 − 3.5 = 88.5 units: an 11.5% loss of the starting position.
Applying 20% and 10% to the entire 100 would overstate this example's exposures. Applying B's percentage to the remaining 92 would also use the wrong denominator. The stated rule applies B's penalty to its 35-unit allocation.
The 25 unallocated units are outside these two modeled service penalties. They are still exposed to the assumed staking pool, base network and contract chain. Calling that row a cash reserve would misrepresent its availability and risks.
Separate allocations also do not establish independent failures. For example, if the same operator runs both services on one infrastructure provider, a shared outage could affect both sets of duties. That is a dependency to investigate, not a reason to invent failure probabilities or add advertised yields into a safety score.
Identify who can change the exposure
The v1.13.0 AllocationManager documentation describes allocation proportions, operator-set registration and the conditions under which an allocation is slashable. It also permits operators to configure an allocation delay, including zero. A historical delay printed in an older launch guide is therefore insufficient evidence for the current position.
Record the operator address, service address, operator-set identifier, asset strategy, current allocation and pending changes. Then record the configured delay and the block at which a pending allocation takes effect. An announcement timestamp and an effective block answer different questions.
Service rules deserve their own review. ELIP-002's slashing specification leaves the reasons and process for service slashing to the service's design. Do not assume every loss must result from Ethereum consensus misbehavior or an automatically verified fraud proof. Identify the authorized slasher, evidence requirements and any service-specific dispute process from the actual implementation.
Also distinguish reducing the claim from disposing of the slashed assets. The v1.13.0 release notes introduce a resolution delay before certain burnable or redistributable shares can be cleared. Record the claim reduction separately from the subsequent burn or redistribution; the latter's waiting period does not establish a spendable holder balance.
An exit request is another state to inspect
Restaking withdrawal, receipt-token redemption and receipt of ordinary ETH are separate milestones. For EigenLayer's documented v1.13.0 arrangement, DelegationManager lists a mainnet withdrawal delay of 100,800 blocks, approximately 14 days at 12-second blocks. Queued shares can still be affected by slashing during the relevant withdrawal period, and completion requires a further call. The output can be tokens or internal shares, so check the selected completion mode.
The pinned completion code makes the block boundary precise. For an LST withdrawal queued at block B, the operator-slashing window includes B + 100,800. Completion requires a block strictly greater than that boundary and uses the slashing factor recorded at the boundary, even if the call arrives later. Exactly 100,800 intervals of 12 seconds equal 14 days; the next block would be 12 seconds later under that assumption. Actual block production and transaction inclusion can add time.
For an LST deposit, receiving the LST back does not itself redeem its ETH backing. Ethereum's pooled staking guide distinguishes protocol redemption from a secondary-market sale. A sale transfers the claim at the available price; redemption follows the staking provider's conditions. The liquid staking discount guide explains why those two exit amounts can differ.
Here is a separate hypothetical exit timeline. Its day labels are rounded, and no provider turnaround is implied. Assume the first completion occurs after the required block boundary and returns an LST, followed by a separate pool redemption; ignore fees and rewards.
| Time | Observed event | What the holder can establish |
|---|---|---|
| Day 0 | Restaking withdrawal queued | A pending request exists; no token receipt yet |
| Day 6 | A qualifying slash reduces the claim | Requesting exit did not freeze the original amount |
| About day 14 | Restaking withdrawal completed as tokens after the eligible block | The adjusted LST amount arrives |
| Day 15 | LST redemption requested | A second process is pending |
| Day 20 | ETH redemption claimed | ETH receipt is now observable |
The full path took about 20 days in this scenario. The approximately one-day gap before the second request and five-day redemption phase are separate assumptions beyond the first completion. Other paths can overlap work, use buffers or return different assets; do not automatically add every advertised delay without checking the required order.
Ethereum's withdrawal documentation separately describes validator exits and consensus-to-execution transfers, while directing pool users to provider-specific rules. The validator exit versus withdrawal guide helps identify whether a base-network milestone is actually the holder's final receipt.
Make the comparison on a dated worksheet
Before comparing staking and restaking positions, fill six fields for each candidate arrangement:
- Backing: the native asset, held instrument and conversion into underlying units at a stated block.
- Inherited conditions: base-network duties, validator operator, and any staking pool or custody dependency.
- Added services: each operator set, permitted loss basis, current allocation, pending changes and shared infrastructure.
- Control: who changes allocations, upgrades contracts, imposes slashing or pauses each exit step.
- Exit sequence: request identifier, remaining conditions, slashability boundary, completion action and asset returned at each stage.
- Reward accounting: which amounts are paid, accrued, conditional or merely promotional; fees and reward-token units kept separate.
Mark an unavailable field unknown. An incomplete service list means the position's added obligations are unresolved, even when a dashboard shows a precise reward rate. A completed restaking withdrawal returning an LST means one dependency ended while the staking redemption dependency remains.
Keep the dependency map beside the allocation and exit records. The useful comparison is whether you can name every added condition on the same backing, identify who can change it, and show the next observable step required to receive the asset you intend to hold.