Coverage scope
Coverage scope decides what the insurance layer can actually absorb. For Lyrasing, a covered event should be tied to a specific AVS exposure, operator fault domain, vault or strategy path, withdrawal state, LRT collateral variant, and insurance capacity record. Anything broader becomes generic reassurance, which is not useful for collateral policy.
This page does not claim active coverage, active reserves, supported collateral, implemented claims, deployed contracts, or a working market.
Coverable surfaces
The strongest candidates for future coverage are slashing events where the surface is observable and the affected collateral path can be bounded:
| Surface | What coverage would need |
|---|---|
| Direct AVS slash | AVS or network identity, operator set, slash condition, affected strategy or vault, amount, and settlement path. |
| Operator-set incident | Operator membership, allocation or captured stake, correlated operator overlap, and whether the same incident can affect other collateral. |
| Vault or strategy slash | Vault identity, epoch, collateral token, delegator or network opt-in state, slashable amount, and Burner route. |
| Withdrawal-period slash | Proof that the pending withdrawal was still slashable at the relevant capture time, delay window, or epoch boundary. |
| Redistribution or burn path | Whether slashed funds are burned, redirected to a recipient, routed through a Burner, held in escrow, or delayed. |
| LRT holder or account impact | Which collateral accounts, wrappers, share rates, balances, or claim objects were impaired after the slash. |
Coverage should follow the source of the slash, not the asset label. A token variant may share a brand with a base asset while carrying a different wrapper, bridge, redemption, oracle, or liquidation path.
Capped and delayed surfaces
Some surfaces may be coverable only with caps or delayed settlement:
| Surface | Why cap or delay |
|---|---|
| Correlated operator incident | One key, infrastructure, or process failure can affect several LRT routes at once. |
| Shared vault exposure | Several networks can draw security from the same vault or collateral path. |
| Veto or appeal window | The event can be known before final slashing execution or cancellation. |
| Pending withdrawal state | A queued exit may remain slashable until a safety delay or vault epoch boundary passes. |
| Redistribution recipient or Burner route | Funds may be redirected, burned, routed, or cleared in a later step. |
| Oracle or NAV staleness | Account impact may be uncertain until the unit accounting source is refreshed. |
Delayed coverage is not a failure of the model. It is often the honest response when the source protocol has review windows, epochs, non-atomic clearing, or post-event reconciliation.
Exclusions
The default exclusions should be explicit:
| Excluded surface | Reason |
|---|---|
| Generic price decline | A market drawdown is not a slashing insurance claim unless it maps to a covered slash surface. |
| Unsupported or unreviewed collateral | Insurance cannot cover an asset variant that never passed collateral review. |
| Wrapper or bridge incident without slash linkage | A bridge failure, wrapper bug, or accounting incident is separate unless the policy expressly includes it. |
| Oracle manipulation or stale feed without slash event | Oracle failure belongs to oracle/risk policy unless coverage is separately defined. |
| Governance, token, or incentive failure | Tokenomics or governance design is not implied coverage. |
| Live-data failure | Missing dashboards, stale APIs, or market data outages are risk inputs, not automatic claims. |
| Loss after capacity depletion | Coverage cannot exceed available and allocated capacity. |
Wrapper and bridge incidents still matter to collateral policy. They can trigger pause, cap compression, delisting review, or no-admission posture through the LRT collateral framework. They should not be quietly folded into slashing insurance unless the policy says so.
Research-only surfaces
Some surfaces should stay research-only until implementation details exist:
| Surface | Research question |
|---|---|
| Cross-protocol socialized loss | Who has the legal or protocol authority to allocate loss across holders? |
| Multi-AVS correlated loss | How is shared insurance capacity allocated when several services claim at once? |
| External backstop draw | Is the backstop enforceable, senior or junior, renewable, and available during market stress? |
| Protocol equity loss | What account represents protocol equity, and when is it allowed to absorb supplier shortfall? |
| Clawback after delayed recovery | What happens if funds are later recovered after suppliers were already paid? |
Research-only means the surface can be studied and documented, not counted in LTV, borrow caps, supply caps, or looping limits.
Source notes
EigenLayer docs support the direct AVS, Operator Set, Unique Stake, burn, and redistribution concepts used here. Symbiotic docs support vault epoch, captureTimestamp, Instant Slasher, VetoSlasher, and Burner routing concepts. The coverage scope is Lyrasing methodology framing only and does not claim coverage for any external token, vault, operator, AVS, or network.