Liquidity and oracles
LRT collateral needs two different evidence streams: market evidence for forced liquidation and accounting evidence for what the token represents. A venue can show depth while the redemption queue is slow. A primary exchange-rate function can be precise while the market is illiquid. A price feed can be fresh while AVS allocation is stale. Lyrasing should treat these as separate inputs.
This page does not specify a live oracle, data provider, or integration. It defines the inputs a future oracle/risk methodology would need to observe.
Liquidity posture
Venue depth is an input, not a guarantee. The review should record:
| Input | Review question |
|---|---|
| Venue set | Which DEX pools, aggregators, OTC desks, or protocol redemption paths could realistically absorb liquidation inventory? |
| Depth unit | Is depth measured against ETH, wETH, stETH, the underlying LRT, stablecoins, or another correlated asset? |
| Concentration | Does most liquidity sit in one venue, one market maker, one bridge domain, or one liquidity program? |
| Stress behavior | What happens when the LRT trades below backing value, queue demand rises, or correlated LRTs are sold together? |
| Exit mismatch | Can secondary liquidity exit faster than primary redemption, and does that create a discount under stress? |
| Inventory source | Is the liquidation route relying on the same protocol buffer, vault, or queue that may already be stressed? |
| Refresh trigger | Which liquidity loss, depeg, delisting, bridge incident, or queue change forces review? |
The key policy question is not “does a pool exist?” It is whether the pool can remain useful when the collateral is being liquidated because its own risk surface changed.
Oracle evidence set
An LRT collateral record should separate price evidence from unit-conversion and exposure evidence:
| Evidence | Purpose | Conservative failure mode |
|---|---|---|
| Market price | Account health and liquidation trigger input. | If stale or thin, compress caps and avoid aggressive LTV. |
| Exchange-rate or share-rate evidence | Convert non-rebasing wrappers, vault shares, or receipt tokens to backing units. | If missing, do not assume one token equals one ETH. |
| NAV or backing disclosure | Check the accounting path from token to underlying collateral. | If primary disclosure is stale, delay admission or downgrade tier. |
| Redemption status | Queue length, finalization state, claimability, buffer state, or epoch timing. | If exit state is stale, treat liquidity as slower than spot price suggests. |
| AVS exposure state | Operator set, network, vault, strategy, or allocation labels from the AVS-risk methodology. | If exposure is stale, price freshness does not rescue the candidate. |
| Insurance capacity | Coverage mapped to the relevant slash surface. | If stale, exclude coverage from LTV support. |
Lido’s wstETH contract exposes conversion methods between wstETH and stETH, and Lido’s withdrawal docs describe queue and claim state. Ether.fi’s withdrawal docs describe both queued withdrawal and an instant redemption route gated by buffer conditions. These are examples of the kind of primary evidence a candidate review should seek; they are not live Lyrasing oracle inputs.
Stale and missing data policy
Lyrasing’s collateral framework should make stale-input behavior predictable:
| Condition | Policy response |
|---|---|
| Price feed is fresh but exchange-rate/NAV evidence is stale. | Keep the asset out of normal LTV review until the unit accounting is refreshed. |
| Exchange rate is fresh but venue depth is stale. | Treat account value as observable but liquidation reliability as unresolved. |
| Liquidity is deep but redemption queue is stressed. | Cap exposure and avoid treating secondary liquidity as permanent backing. |
| AVS exposure or operator set is stale. | Consume the AVS-risk methodology’s opaque-exposure label and compress caps. |
| Insurance capacity is stale or generic. | Exclude insurance from the policy argument. |
| Any required input is missing. | Delay admission, use research-only classification, or assign no collateral factor. |
No manual override should turn stale data into normal LTV. A future protocol may have human or governance discretion, but the documentation baseline should make the conservative response the default.
No live-data boundary
This repository should not fetch live TVL, APY, DEX depth, Chainlink feeds, EigenLayer state, Symbiotic vault data, Lido queue state, ether.fi buffer state, or any other live market/protocol input. All examples in this section are methodology examples. They do not represent current supported collateral, production data feeds, or active oracle implementation.
Source notes
EigenLayer and Symbiotic sources support the exposure and timing inputs that sit beside price. Lido and ether.fi sources support the token-accounting and redemption-evidence examples. Third-party market dashboards can help a future review find venues, but policy should depend on primary protocol sources and directly observable state.