Onboarding criteria
An LRT candidate should enter Lyrasing review only when the review can separate observable collateral facts from assumptions. The candidate may have deep secondary liquidity, a familiar ticker, or a tight ETH market price. None of that is enough if the backing, restaking route, exit path, AVS exposure, or slash treatment is opaque.
This page defines the admission inputs a future market would need before any collateral factor, borrow cap, looping limit, or supported-list record can be considered. It does not approve any asset.
Admission inputs
| Input | Required evidence |
|---|---|
| Backing and staking route | Underlying ETH, LST, LRT, vault share, receipt, or wrapped asset; native staking, liquid staking, vault, or wrapper path. |
| Restaking route | EigenLayer strategy, Symbiotic vault/network, operator set, or other shared-security path that can create additional commitments. |
| Wrapper or rebasing mechanics | Whether balances rebase, accrue through exchange rate, wrap another token, or represent a queued claim. |
| Redemption and exit timing | Primary redemption route, secondary-market exit, withdrawal queue, vault epoch, safety delay, veto window, claim object, and cancellation rule. |
| Liquidation liquidity | Venue set, route concentration, inventory source, stress behavior, and whether depth depends on the same stressed system. |
| Price, NAV, and exchange-rate evidence | Price feed, share-rate or wrapper conversion, NAV/backing disclosure, freshness rule, and stale-input fallback. |
| AVS and operator exposure | Services, networks, operator sets, operators, vault allocations, and correlated fault domains from the AVS-risk methodology. |
| Slash treatment and insurance mapping | Burn, redistribution, Burner route, escrow, socialization, covered surface, capacity, exclusions, trigger, and payout order. |
| Discretion and variants | Governance, curator, resolver, multisig, bridge, wrapped variant, or admin path that can alter risk or accounting. |
| Review cadence | Event triggers for operator-set change, vault-epoch change, redemption stress, oracle outage, insurance change, or liquidity loss. |
Candidate-review checklist
The first review should produce a record with enough detail for a second risk engineer to reproduce the classification:
- Candidate identity: token contract, chain, wrapper relationship, and source documentation.
- Backing map: underlying asset path from deposit to token accounting unit.
- Redemption map: primary redemption steps, secondary exit venues, queue or epoch timing, claim object, and non-cancelability if applicable.
- Unit accounting: whether the balance rebases, accrues through exchange rate, or needs wrapper conversion during oracle and liquidation flows.
- Exposure map: AVS, network, operator-set, operator, vault, strategy, and insurance coupling references.
- Timing envelope: allocation delay, withdrawal delay, vault epoch, veto or appeal window, settlement path, and claim timing.
- Liquidity/oracle posture: venue stress assumption, liquidation route, price source, exchange-rate/NAV source, exposure source, freshness threshold, and fallback policy.
- Policy output: qualitative tier, cap posture, looping posture, refresh triggers, and unresolved blockers.
The checklist should explicitly cite primary sources for protocol mechanics. Third-party dashboards can help locate venues or liquidity history, but they should not set policy by themselves.
Admission gates
The minimum gates are intentionally conservative. Backing, wrapper, redemption, and restaking route must be source-backed or directly observable. AVS/network allocation and operator exposure must be classifiable through the AVS-risk methodology. Liquidation must have a plausible route that does not rely on the same stressed system for every exit. Price and exchange-rate/NAV units must be clear enough to avoid double-counting or stale conversion. Withdrawal, epoch, veto, safety-delay, and claim windows must be comparable with liquidation response time. Insurance must map to the exact slash surface, not to the asset brand in general. A future risk owner must be able to refresh the record when primary inputs change.
Failing one gate does not automatically mean permanent rejection. It means the candidate should remain delayed, cap-compressed, or research-only until the missing input becomes observable.
Non-claim boundary
Lyrasing currently has no supported collateral list, deployed markets, oracle contracts, active LTV parameters, live data feeds, governance UI, direct LRT integrations, or working app. This page defines future admission evidence only.
Source notes
EigenLayer’s Operator Sets and Unique Stake documentation make operator opt-in, allocation, and slashable stake part of the risk surface. Symbiotic’s vault and slashing documentation makes opt-ins, capture timestamps, vault epochs, and Burner routing part of the review. Lido’s token integration guide and ether.fi’s eETH/weETH docs are useful examples of wrapper, queue, and redemption mechanics; they are not Lyrasing support claims.