Trigger and claims

A claims process begins with evidence, not with sympathy for a loss. A future Lyrasing insurance review would need to prove that a covered slash surface was hit, that the affected collateral accounts are inside scope, that capacity was available before the event, and that the payout waterfall can be applied without inventing accounting after the fact.

There is no implemented claims process, claims UI, governance process, contract, reserve, oracle implementation, or active coverage in this repository.

Trigger evidence

The evidence package should identify the event and the affected collateral state:

• Event source: AVS, network, vault, strategy, Operator Set, operator, or other path that created the slash surface.
• Timing context: capture timestamp, vault epoch, safety delay, withdrawal state, veto window, or other period that made the stake slashable.
• Execution proof: transaction, event, state transition, request record, or source-backed evidence that slashing executed or became pending.
• Amount and unit: token, share, strategy, vault collateral, wrapper unit, redemption claim, or lending-account value affected.
• Settlement path: burn, redistribution, Burner route, escrow, delayed clear, or other outflow route.
• Freshness and capacity: block range, source version, stale-input status, and insurance capacity allocated before the event.

Trigger evidence should be durable enough that a reviewer can reconstruct the event from primary sources or directly observable state. A third-party dashboard can help locate the event, but it should not be the final authority.

Who can submit

A future design could allow several submitter classes:

• Affected supplier or borrower provides account impact and collateral position evidence.
• Risk owner or keeper provides the source-backed event packet and capacity snapshot.
• AVS, network, operator, or vault team provides primary incident details, slash condition, and settlement status.
• External researcher can submit reproducible evidence for review, without privileged payout authority.

Submission rights are not payout rights. The claims process should separate who can submit evidence from who can verify it, reserve capacity, approve payout, dispute the claim, or update collateral policy.

Verification steps

The review path should be deterministic and produce one status: rejected, pending evidence, reserved-capacity pending settlement, approved, partially approved, or research-only.

Scope review maps the event to a covered AVS, operator, vault, strategy, withdrawal, or LRT collateral surface. Timing review checks whether the stake was slashable at capture, request, execution, or withdrawal boundary. Amount review checks the token, share, wrapper, or accounting unit. Account-impact review checks borrower collateral, supplier assets, redemption claims, and market solvency. Capacity review checks whether mapped insurance was available before the event and not already consumed. Waterfall review applies liquidation proceeds, borrower residual equity, reserves, and recoveries in the right order.

Disputes and appeals

Slashing systems can include veto periods, appeal-like processes, delayed settlement, or non-atomic clearing. A pending veto or resolver window can reserve capacity, but it should not finalize payout. Delayed settlement should leave the account impact pending reconciliation. Contradictory evidence should keep the claim unresolved and compress related caps. Account disputes should reconcile token units, share rates, and withdrawal status before payout. Later recovery or redistribution should follow only the clawback or reconciliation rule that existed before the payout.

There is no promise that every unresolved event becomes covered. Unresolved evidence should lower risk appetite until it is clear, not become an excuse for instant supplier compensation.

No implemented process boundary

This page defines review language. It does not create a live intake form, contract role, claims committee, governance vote, dispute process, payout formula, or legal promise. A real implementation would need separate contracts, operations, accounting, incident response, and user communication design.

Source notes

EigenLayer docs support AVS-determined slashing, Operator Sets, Unique Stake, safety delays, queued withdrawal slashability, burning, and redistribution. Symbiotic docs support captureTimestamp, vault epoch, slashableStake, VetoSlasher request/veto/execute stages, and Burner routing. Lyrasing uses those mechanics to define evidence requirements only.