A liquid staking token (LST) represents a claim linked to staked assets and their staking results. A liquid restaking token (LRT) represents a claim on a position that also supports additional services under restaking rules. Both can trade while backing remains committed. Compare the backing, who allocates it, how losses reach the token, and the asset returned by redemption; transferability does not make the underlying immediately available.
Follow the backing before comparing tickers
For an Ethereum LST, the starting relationship is between a token holder and a staking arrangement. Ethereum's pooled staking documentation explains that the holder owns a claim on the pool's contracts or service, while Ethereum pays rewards to validators. The token adds pool, operator and governance dependencies to the underlying staking exposure.
An LRT adds restaking conditions to its backing. However, its name does not tell you whether a separately issued LST sits underneath it. Two documented routes illustrate the distinction:
- Through an existing LST: an LRT manager accepts an LST and arranges its restaking. The holder then depends on both the LRT arrangement and the original staking token. Renzo's ezETH documentation describes ezETH as a claim on a restaked position and documents both native ETH and stETH deposit routes.
- Through native ETH: a provider operates a staking and restaking arrangement without requiring a third-party LST as an intermediate asset. The ether.fi contract repository describes ETH deposits issuing eETH or its wrapper weETH, with validator withdrawal credentials pointing to EigenLayer EigenPods.
These are architecture examples from documentation inspected on 28 October 2026, rather than live checks of accepted deposits, allocations or available withdrawals. A mixed backing pool can contain several paths. The asset you originally deposited also need not remain a separately identified reserve for your eventual withdrawal.
Wrapping is another distinction. Lido's wstETH documentation describes a wrapper whose balance does not rebase with oracle reports, while its stETH conversion changes. Unwrapping returns stETH. The wrapper operation itself does not introduce restaking. Conversely, ether.fi describes weETH as a wrapper around eETH within its native restaking architecture. The letter “w” identifies neither the economic obligations nor the final exit asset.
Identify the decisions that sit above the staking claim
With an LST held directly, investigate the staking pool's validators, loss accounting, contract controls and redemption process. With an LST-backed LRT, retain those questions and add the restaking manager's operator selection, service commitments, allocation changes and loss distribution among holders.
For one documented design, EigenLayer's ELIP-002 introduces operator sets and allocations of Unique Stake subject to service-specific slashing. An operator's service count alone therefore does not establish how much backing can be reduced. The relevant evidence is the effective allocation and the applicable conditions.
The token holder may have no direct choice over those decisions. Identify who can change them, when changes become effective and how the token's accounting reflects a loss. The restaking versus staking guide examines those additional duties and allocation rules; here the task is to connect them to the particular receipt in the holder's wallet.
Reconcile one reserve through two receipt layers
Consider a hypothetical LST-backed LRT with invented symbols, quantities and rates. This is an accounting exercise, not a description of any named provider's assets or slashing implementation. Assume no fees, rewards, debt, deposits or rounding during the example.
The base staking pool has 120 ETH backing 100 LST units, giving a conversion of 1.20 ETH per LST. An LRT manager holds 60 of those LST units, worth 72 ETH on that accounting basis, and has issued 50 LRT units. The remaining 40 LST units are held outside the LRT arrangement.
One person's wallet holds 10 LRT and 5 LST directly. The person's 5 LST are part of the 40 units outside the manager, not an additional pool deposit.
| Record at the snapshot | Quantity | Converted backing or claim |
|---|---|---|
| Entire base staking pool | 100 LST outstanding | 120 ETH |
| LST held by the LRT manager | 60 LST | 72 ETH |
| LST held outside the manager | 40 LST | 48 ETH |
| Entire LRT supply | 50 LRT | The same 72 ETH |
| Person's LRT holding | 10 LRT | 14.40 ETH |
| Person's direct LST holding | 5 LST | 6 ETH |
The manager's accounting rate is 72 / 50 = 1.44 ETH per LRT. The person holds 20% of the LRT supply, so their indirect exposure is 20% of 60 LST: 12 LST representing 14.40 ETH. Adding the direct 6 ETH gives a total accounting claim of 20.40 ETH.
Those 12 LST are a view through the 10 LRT, not another wallet holding. Adding 14.40 ETH for the LRT, 14.40 ETH for its underlying LST and 6 ETH for the direct holding would incorrectly produce 34.80 ETH. Similarly, adding the base pool's 120 ETH and the LRT pool's 72 ETH would double-count backing.
A provider's actual rate needs its documented accounting method. Renzo's integration guide derives an ETH-denominated ezETH exchange rate from protocol TVL divided by token supply. Its TVL spans several asset locations, and the calculation can revert. Save the observation block, units and successful result; a failed read does not establish zero backing or validate an old rate.
If borrowing or another product adds leverage, put the debt and exposure rule on separate lines. The leveraged-token daily reset guide explains a different exposure mechanism; the LRT label supplies no leverage multiple.
Apply a loss to the layer that actually bears it
Continue the hypothetical example. Assume a service penalty transfers 3 LST from the restaked pool to a penalty recipient. This invented transfer-based rule leaves the base LST's 1.20 ETH conversion unchanged and reduces only the backing of the LRT pool. It is not EigenLayer's slashing formula.
The manager now holds 57 LST representing 68.40 ETH. With 50 LRT still outstanding, its rate becomes 68.40 / 50 = 1.368 ETH per LRT. The person's 10 LRT represent 13.68 ETH; their 5 directly held LST still represent 6 ETH. Their combined claim falls to 19.68 ETH.
The loss is 0.72 ETH, or approximately 3.5294% of the starting 20.40 ETH. The LRT portion loses 5%, because the 3.60 ETH penalty is 5% of its original 72 ETH backing. Applying that 5% to the person's entire combined position would incorrectly penalize the direct LST holding as well.
The transfer also reconciles globally: the manager's 68.40 ETH-equivalent, the original outside holders' 48 ETH-equivalent and the recipient's 3.60 ETH-equivalent still total 120 ETH. Ownership changed; this assumed event did not destroy the base reserve.
Change the event and the result changes. If a base staking loss instead reduces the ETH represented by every LST, both the direct LST and the LRT's LST backing can be affected. Two tickers can share that underlying dependency. Conversely, the example's restaking-only penalty reaches only the pool that accepted the added condition. Keep the loss basis, affected assets and accounting update in the same record.
Name the asset delivered at every exit step
“Redeemable” needs an output asset and conditions. A token sale delivers the quoted market asset if the trade executes. Protocol redemption can return an LST, ETH or another permitted collateral asset, depending on the provider and route.
Renzo's withdrawal documentation describes a flow where ezETH is locked in a withdrawal contract when requested and burned at claim in exchange for underlying collateral. Buffer capacity and cooldown are configurable parts of that flow. Its ezETH FAQ separately states that reward accrual stops on initiation. Neither behavior is a universal LRT rule.
For the invented pool above, assume completed redemption burns the submitted LRT and returns a proportional amount of LST after the service penalty, with no additional costs or changes. The person's 10 LRT would then return 13.68 / 1.20 = 11.40 LST. That completes the LRT exit, while the LST's own redemption conditions remain.
The manager would retain 45.60 LST backing the remaining 40 LRT, preserving the 1.368 ETH-per-LRT rate. The person's separate 5 LST remain theirs throughout. After receiving 11.40 LST, they hold 16.40 LST in total, still representing the same 19.68 ETH accounting claim.
| Hypothetical state | Record for the 10-LRT exit | What remains to establish |
|---|---|---|
| LRT held | 10 LRT | Current rate and exit eligibility |
| LRT committed to withdrawal | One pending request | Final amount and claim conditions |
| LRT withdrawal completed | 11.40 LST | LST redemption conditions |
| LST redemption completed | ETH receipt | Actual amount and transaction costs |
In this assumed sequence, the pending request replaces the spendable LRT position. Do not count both the request and its expected output as available assets. If normal LST settlement ultimately delivers 13.68 ETH, record that receipt at completion, rather than presenting it as cash available when the LRT request was submitted.
The LST discount guide separates protocol conversion from a size-specific market quote. For a market exit, inspect the pool design too: the constant product versus StableSwap comparison explains why assets with similar reference values can still have changing execution prices. A thin market or a congested redemption route can matter even when the accounting rate is unchanged.
Keep a dated claim worksheet
Make one worksheet per token contract, chain and observation block. Fill these fields before treating two holdings as separate exposures:
- Owned receipt: wallet quantity, token form and any bridge, custody or additional vault layer.
- Backing path: native ETH, each underlying LST, buffers and the corresponding conversion method. Mark intermediate assets already represented by another row.
- Control and conditions: staking operators, restaking operators, service allocations, loss authority, pending changes and upgrade or pause powers.
- Accounting evidence: successful rate observation, total supply, included assets, unit scaling and treatment of pending withdrawals. Mark an unmatched balance or stale rate unresolved. Keep reward assets in their own denominations.
- Loss test: specify one event, the assets it reaches and how the holder's claim changes. Check direct and indirect holdings for the same dependency.
- Exit evidence: asset returned at each step, request state, reward treatment while pending, costs and the next required action. Leave unresolved timing unresolved.
Finish by writing two amounts: the consolidated underlying claim at the observation block, and the amount actually available through the chosen exit. Keeping those amounts beside the dependency path makes an LRT–LST comparison reproducible without mistaking another receipt for another reserve.