Observable inputs
An AVS-aware collateral policy starts by separating what Lyrasing can observe from what it can only infer. The same LRT price can hide very different restaking paths, so the methodology treats price as the first input, not the final risk answer.
Input set
The minimum input set for an LRT collateral review is:
| Input | Why it matters |
|---|---|
| Market price and liquidity | Liquidation still depends on market depth, oracle freshness, and exit liquidity. |
| Backing and redemption path | The LRT’s backing asset, withdrawal route, queue, and claim timing determine whether price can be realized. |
| Service or network allocation | AVSs or networks define the work performed and the commitments that can become slashable. |
| Operator set | Operator membership determines which infrastructure can create direct or correlated loss. |
| Operator overlap | The same operator appearing across several services, networks, or LRT routes can turn independent-looking collateral into one correlated fault domain. |
| Vault or reused collateral path | A shared vault, strategy, or collateral pool can expose positions to the same slash or withdrawal guarantee. |
| Slash conditions | The methodology needs the trigger, evidence standard, maximum slashable amount, and burn or redistribution path. |
| Timing windows | Allocation delay, withdrawal delay, epoch length, veto or appeal period, and settlement delay all affect solvency timing. |
| Insurance capacity | Coverage counts only when it is mapped to the specific slash surface, cap, trigger, and payout order. |
| Discretionary inputs | Governance, curator, resolver, or multisig choices matter when they can alter allocation, veto, burn routing, or coverage. |
Observation quality ladder
Inputs should be labeled by observation quality before they influence LTV:
| Quality tier | Treatment |
|---|---|
| Direct on-chain state | Highest confidence when the contract, chain, block range, and decoding path are known. |
| Primary protocol documentation | Acceptable for methodology framing when it describes the protocol rule, not a live value. |
| Primary off-chain disclosure | Useful for review, but it should not be treated like an oracle feed unless freshness and update responsibility are explicit. |
| Derived or third-party summary | Research support only; it should not set admission, caps, or LTV by itself. |
| Stale input | Conservative default until refreshed. Staleness should compress caps or pause admission rather than invite a manual override. |
| Missing input | No admission, admission delay, or a research-only classification until the missing surface is observable. |
| Discretionary or governance-controlled input | Higher uncertainty unless the update path, delay, and veto or appeal process are observable. |
Stale and missing policy
The policy response should be predictable:
| Condition | Response |
|---|---|
| Price is fresh, AVS allocation is stale. | Do not raise confidence from price alone; cap exposure until allocation is refreshed. |
| Operator set is missing. | Treat operator correlation as unknown and delay collateral admission. |
| Slash conditions are not published in a primary source. | Do not assign normal LTV; require a source-backed review. |
| Withdrawal or epoch timing is stale. | Assume the longer or more conservative window until confirmed. |
| Insurance pool capacity is stale. | Do not count the pool as available coverage for new leverage. |
| Governance or resolver path is unclear. | Treat the input as discretionary and require a higher review tier. |
This is not a claim that Lyrasing already has an oracle. It is the admission standard a future oracle or risk committee would need to satisfy. If the input cannot be observed, the honest policy output is cap compression, admission delay, or no admission.
Source notes
EigenLayer’s current documentation frames Operator Sets, Unique Stake, safety delays, and AVS-controlled slashing as first-class risk surfaces. Symbiotic’s current documentation makes vault epoch accounting, capture timestamps, slashable stake, slasher type, and Burner routing part of the observable risk model. These sources support the input taxonomy above; they do not imply that Lyrasing has implemented live integrations with either system.