Slashing-insurance design
Lyrasing’s insurance premise is narrow: restaking-specific loss should be mapped to the same AVS, operator, vault, strategy, withdrawal, and LRT collateral surfaces that created the exposure. Insurance is not a generic promise that every impaired position is made whole. It is a policy layer that would decide which slash surfaces can be funded, capped, delayed, excluded, or left as research-only before suppliers absorb a shortfall.
This section is still pre-launch design content. It does not claim an implemented pool, active coverage, active reserve, deployed contract, governance process, oracle implementation, payout formula, supported collateral, live market, or working app. The purpose is to define the review language a future protocol would need before any reserve, fee route, claim process, or accounting implementation exists.
Reading model
The section is split into five child pages:
- Pool funding defines future funding sources, fee-routing posture, reserve capitalization, replenishment, depletion, and the no-tokenomics boundary.
- Coverage scope separates coverable slash surfaces from capped, delayed, excluded, and research-only surfaces.
- Trigger and claims defines evidence, submission posture, verification, disputes, and unresolved evidence handling.
- Payout waterfall orders borrower collateral, liquidation proceeds, reserves, insurance capacity, supplier shortfall, protocol equity, delayed settlement, and reconciliation.
- Capacity and policy connects thin capacity to caps, LTV posture, liquidation threshold posture, looping limits, review cadence, and pause or delisting decisions.
What insurance must map to
A future insurance record should be tied to a concrete risk surface:
- AVS or network: which service created the slash condition, and was the relevant stake allocated or captured for that service?
- Operator set or operator: which operator, operator set, or correlated cluster was responsible for the fault domain?
- Vault, strategy, or reused collateral path: which route carried the slashable position?
- Withdrawal or epoch state: was the affected stake still slashable during a queue, vault epoch, safety delay, veto period, or settlement window?
- LRT collateral record: which token variant, wrapper, bridge path, redemption route, and oracle unit was affected?
- Insurance capacity: was there reserved capacity for this surface before the event, or was coverage generic and unusable for policy?
The AVS-risk methodology owns the exposure and timing labels. The LRT collateral framework owns token mechanics, redemption paths, oracle units, and supported-list boundaries. This section consumes those labels and asks whether a future reserve could absorb a defined loss without hiding the residual risk from suppliers.
Design posture
The conservative posture is fail-closed. If the slash surface, timing window, affected account set, claim evidence, or available capacity is unclear, insurance should not be counted as support for LTV, caps, or looping. It can be recorded as unresolved research, but it should not become coverage by prose.
The strongest insurance design is boring and auditable: a defined funding source, a defined covered surface, a defined trigger, a defined payout order, and a defined capacity constraint. Anything else is marketing reassurance.
Source posture
Insurance claims in this section were checked against current primary EigenLayer slashing , EigenLayer redistribution , EigenLayer safety-delay , and Symbiotic slashing documentation. Those sources support the slash, timing, redistribution, vault-epoch, VetoSlasher, and Burner concepts used here. They do not imply that Lyrasing has integrated with any external protocol or launched insurance coverage.