Backing and redemption
Backing and redemption decide whether a collateral value can be realized when a borrower is unhealthy. For LRTs, this is not just “what does the token trade for?” It is a map from the token accounting unit to the underlying asset, staking route, restaking route, wrapper mechanics, primary redemption path, secondary exit path, and any timing window that can delay or impair the exit.
The review should treat every wrapper and chain variant as its own asset until proven otherwise. A bridged, wrapped, vault-issued, or exchange-rate token can share a brand with a base asset while adding different oracle, redemption, and liquidation assumptions.
Backing map
| Surface | What to record | Why it matters |
|---|---|---|
| Backing asset | ETH, LST, LRT, vault share, claim token, or wrapped representation. | The market needs to know what can be recovered after liquidation or redemption. |
| Staking path | Native validator path, liquid staking protocol, vault module, or delegated strategy. | Validator or protocol-level penalties can change the backing value. |
| Restaking path | EigenLayer strategy, Operator Set, Symbiotic vault/network, or another shared-security path. | Restaking adds slash and timing surfaces beyond base staking. |
| Accounting unit | Rebasable balance, non-rebasing exchange-rate wrapper, share token, or NFT claim. | Oracle and liquidation logic must use the right unit. |
| Chain and wrapper variant | Canonical token, bridged token, wrapped token, or protocol-specific receipt. | Bridge and wrapper risk should not inherit policy automatically. |
| Upgrade or admin surface | Governance, curator, resolver, multisig, or proxy path that can change mechanics. | Discretion changes the refresh cadence and risk tier. |
Lido’s current documentation illustrates why this matters: stETH is a rebasable token representing withdrawable ether, while wstETH is a non-rebasing wrapper whose value in stETH changes through an exchange-rate relationship. Ether.fi’s docs present eETH and weETH as a rebasing/restaking token pair with wrapped DeFi compatibility. These are examples of mechanics a review must understand; they do not imply Lyrasing collateral support.
Redemption routes
Collateral review should separate primary redemption from secondary-market exit:
| Route | Review focus |
|---|---|
| Primary redemption | Protocol-native path to ETH, LST, or underlying collateral, including queue, claim object, finalization, and cancellation rules. |
| Secondary-market exit | DEX, aggregator, OTC, or market-maker route, including depth, slippage, routing concentration, and stress assumptions. |
| Instant or buffered redemption | Whether the route depends on protocol inventory, liquidity buffer, fee, rate limit, or low-watermark condition. |
| Vault epoch exit | Whether withdrawal becomes claimable only after the next epoch boundary and remains slashable until then. |
| Delayed claim path | Whether the holder receives an NFT, receipt, queued request, or other claim object before final ETH or token delivery. |
| Cross-chain exit | Whether settlement depends on a bridge, messaging layer, canonical burn/mint, or external liquidity. |
Primary redemption is stronger evidence for solvency than secondary liquidity, but it can be slower. Secondary markets can be faster, but venue depth can evaporate exactly when liquidation demand appears. A credible policy uses both inputs and does not let one erase the other.
Queue and epoch timing
Queued exits are collateral inputs, not UX footnotes. Lido’s withdrawal flow is organized as a FIFO queue: a user requests withdrawal, receives an NFT for the queue position, waits for oracle finalization, and then claims ETH. Symbiotic vault withdrawals are epoch-based: requests become claimable after the next vault epoch and remain slashable until that boundary. Ether.fi documents both a standard queued withdrawal path and an instant redemption path that depends on buffer liquidity and limits.
For Lyrasing review, the output should be a timing envelope:
| Timing item | Policy question |
|---|---|
| Request time | When does the collateral stop being transferable or liquid? |
| Finalization trigger | Is finalization driven by an oracle report, protocol inventory, epoch boundary, resolver process, or external settlement? |
| Claim time | When can the holder actually receive ETH or the underlying asset? |
| Slashability during exit | Can the pending withdrawal still be slashed before claim? |
| Cancellation | Can the request be canceled, transferred, repriced, or discounted? |
| Buffer exhaustion | What happens when an instant route has insufficient inventory? |
If the liquidation model assumes faster realization than the primary redemption path can provide, the asset should move toward cap compression, lower LTV, or no looping.
Impairment paths
The backing map should also record how losses affect redemption:
| Event | Review treatment |
|---|---|
| Validator penalty or base staking loss | Check whether token share rate, rebasing balance, or claim amount can fall. |
| AVS slash | Map the slash to the operator set, vault, strategy, burn, redistribution, or Burner route. |
| Queue stress | Treat longer queues as liquidity and timing risk, even if the accounting unit remains valid. |
| Protocol inventory stress | Do not assume instant redemption if the buffer is low or rate-limited. |
| Bridge or wrapper incident | Review bridged/wrapped variants separately from canonical token mechanics. |
Non-claim boundary
This page is methodology framing. Lyrasing has no redemption adapter, vault integration, supported collateral, deployed market, oracle contract, or liquidation system in this repository.
Source notes
Primary sources used for this page: Lido token integration and wstETH docs for rebasing/wrapper and withdrawal-queue mechanics; ether.fi eETH/weETH and withdrawal docs for rebasing/wrapped LRT and queued/buffered redemption examples; Symbiotic vault docs for epoch-based withdrawals and slashability; EigenLayer docs for operator-set slashing and safety-delay framing.