Supported-list policy
A supported list is a future protocol record, not a marketing page. It should only exist when Lyrasing has deployed markets, oracle infrastructure, risk ownership, and parameters that can be refreshed. Until then, this documentation defines the record shape and review process without claiming that any asset is supported.
The current state is explicit: Lyrasing has no supported collateral list, no deployed markets, no oracle contracts, no active LTV parameters, no governance UI, no direct LRT integrations, and no working app.
Future record shape
Each future supported-list entry should be a structured record:
| Field | Purpose |
|---|---|
| Asset identity | Token name, symbol, contract, chain, wrapper relationship, and canonical source. |
| Variant status | Canonical, wrapped, bridged, vault share, receipt, or claim token. |
| Backing path | Underlying asset, staking route, restaking route, and accounting unit. |
| Redemption path | Primary redemption steps, secondary exit assumptions, queue/epoch timing, claim object, and buffer/rate-limit notes. |
| Oracle inputs | Price feed, exchange-rate/NAV feed, exposure feed, freshness threshold, fallback behavior, and manual-review trigger. |
| Liquidity inputs | Venue set, stress depth assumption, route concentration, and stale-depth policy. |
| AVS-risk labels | Exposure taxonomy, operator correlation, slashability timing, and stale/missing-input labels. |
| Insurance mapping | Covered slash surface, capacity, exclusions, payout order, and refresh trigger. |
| Parameters | Future cap, LTV, liquidation, and looping posture, once implemented. |
| Review metadata | Reviewer, source URLs, access date, next review trigger, and delisting trigger set. |
The record should be auditable from primary sources and directly observable state. If a field cannot be filled honestly, the entry should not become normal supported collateral.
Admission process
| Step | Output |
|---|---|
| Intake | Candidate identity, source list, and reason for review. |
| Mechanics review | Backing, wrapper, redemption, chain variant, and accounting-unit map. |
| AVS-risk review | Exposure taxonomy, operator correlation, slashability timing, and stale/missing-input classification. |
| Liquidity/oracle review | Price, exchange-rate/NAV, redemption state, venue depth, and stale-input policy. |
| Insurance review | Coverage scope, capacity, exclusions, trigger process, and payout order. |
| Tier decision | Qualitative risk tier with unresolved blockers and cap posture. |
| Parameter proposal | Only after implementation exists: proposed caps, LTV, liquidation threshold, loop depth, and refresh rules. |
| Publication | Supported-list record with sources and review cadence. |
Admission should fail closed. A candidate can be interesting, liquid, or widely held and still be delayed if the restaking route, operator set, redemption path, or oracle unit is not reviewable.
Review cadence
A supported-list record should refresh on a calendar and on events:
| Trigger | Required action |
|---|---|
| Operator set, network, vault, or strategy change | Re-run AVS-risk exposure and correlation review. |
| Slashing rule, veto process, Burner route, or redistribution change | Re-map slash treatment and insurance coverage. |
| Wrapper, bridge, or token contract change | Re-review accounting unit and variant status. |
| Withdrawal queue, vault epoch, or buffer stress | Re-evaluate redemption timing and liquidation assumptions. |
| Liquidity loss, venue delisting, or routing concentration | Compress caps or pause new exposure until depth is refreshed. |
| Price feed, NAV, or exchange-rate input stale | Move to compressed/delayed posture until source freshness returns. |
| Insurance payout or capacity change | Recalculate whether coverage still maps to the relevant slash surface. |
Cadence is not a substitute for event-driven review. LRT collateral can change because of operator, vault, protocol, bridge, and market events between scheduled reviews.
Delisting triggers
Delisting should be considered when:
| Trigger | Reason |
|---|---|
| Primary backing or redemption source becomes unavailable. | The collateral cannot be audited. |
| Required oracle or exchange-rate input is stale beyond policy. | Account health may be using the wrong unit. |
| AVS exposure becomes opaque or materially more correlated. | The prior tier no longer describes the risk. |
| Withdrawal route becomes unreliable or claim timing expands materially. | Liquidation assumptions may fail. |
| Slashing process changes without source-backed bounds. | Loss severity or settlement path cannot be modeled. |
| Bridge/wrapper incident affects the listed variant. | The variant may no longer inherit base token assumptions. |
| Insurance mapping fails or capacity is consumed. | Coverage cannot support the prior cap/LTV posture. |
Delisting does not have to mean immediate forced exit. Future protocol design would need a separate process for pause, cap-to-zero, borrow-disable, liquidation-only mode, and unwind windows. This page only defines the policy trigger language.
Publication boundary
The docs may mention external protocols as mechanics examples, such as Lido’s stETH/wstETH wrapper and withdrawal queue or ether.fi’s eETH/weETH redemption paths. Those examples are source patterns. They are not supported-list entries and should never be phrased as “Lyrasing supports” any named asset.
Source notes
The record shape follows from the current AVS-risk methodology plus primary EigenLayer, Symbiotic, Lido, and ether.fi documentation. Exact source URLs and access dates are tracked in the session report for this content batch.