LRT collateral framework
This section defines how Lyrasing would evaluate LRT collateral before any supported-list claim, market deployment, oracle contract, or live LTV parameter exists. It is a review framework for future protocol work, not a collateral configuration.
The core rule is direct: price proximity to ETH is not enough. An LRT can trade near ETH while carrying a different restaking route, wrapper shape, withdrawal path, operator set, AVS exposure, slashing treatment, insurance mapping, and liquidation profile. Lyrasing therefore treats market price as one input inside a collateral review, not as the admission test.
Reading model
The framework is split into five child pages:
| Page | What it owns |
|---|---|
| Onboarding criteria | Admission inputs and the candidate-review checklist a future risk owner would need before assigning any collateral policy. |
| Backing and redemption | Backing asset, wrapper or rebasing mechanics, primary redemption, secondary-market exits, queues, epochs, and delayed claim paths. |
| Liquidity and oracles | Liquidation liquidity, venue assumptions, price feeds, NAV or exchange-rate evidence, stale-input policy, and no-live-data boundary. |
| Risk tiers | Qualitative collateral bands that consume AVS-risk labels without pretending a numeric parameter engine exists. |
| Supported-list policy | Future record shape, admission/delisting process, review cadence, and the current no-supported-collateral boundary. |
Evaluation dimensions
Candidate LRT collateral should be reviewed across at least these dimensions:
| Dimension | Review focus |
|---|---|
| Backing | What asset, staking route, restaking route, wrapper, bridge, or vault path the token represents. |
| Redemption | Whether primary exits are synchronous, queued, epoch-bound, inventory-limited, delegated, or delayed by a claim path. |
| Liquidity | Where liquidation inventory can realistically be sourced without circular assumptions about stressed markets. |
| AVS exposure | Which services, operator sets, networks, or vault allocations can change the collateral risk. |
| Operator exposure | Which operators, operator clusters, or infrastructure providers create direct or correlated fault domains. |
| Slashing treatment | Whether losses are burned, redistributed, routed through a burner, insured, delayed, or socialized. |
| Oracle support | Which price, NAV, exchange-rate, redemption, and exposure inputs can be observed with acceptable freshness. |
| Discretion | Which governance, curator, resolver, multisig, or committee actions can alter admission risk. |
Admission posture
An LRT should not receive a collateral factor merely because it trades near ETH. The framework should tie any future LTV to the asset’s backing, slash surface, exit path, and observable risk data. If those inputs are unavailable, the honest answer is a lower cap, a lower LTV, or no admission.
The AVS-risk methodology pages provide the upstream labels for exposure, operator correlation, slashability timing, and stale or missing inputs. The LRT collateral framework uses those labels to decide whether a candidate is reviewable, cap-compressed, delayed, or out of scope. It should not repeat the entire taxonomy on every page.
Source posture
This section uses current primary protocol documentation as methodology evidence:
- EigenLayer sources define Operator Sets, Unique Stake, strategy magnitudes, slashing flexibility, redistribution/burn paths, and safety-delay categories.
- Symbiotic sources define vault epochs, opt-ins, capture timestamps, slashing request processing, VetoSlasher timing, and Burner routing.
- Lido and ether.fi sources are used only as token-mechanics examples for wrapper/rebasing behavior, withdrawal queues, and liquidity-buffered or queued redemption paths.
Those source notes do not imply Lyrasing support for any external token, protocol, market, oracle, integration, or collateral parameter. Exact URLs and access dates are recorded in the session report.