Claims Process

Firelight does not require program operators to file claims. When a covered incident occurs, the protocol identifies every active Cover Token exposed to the affected market and includes it automatically. No portal, no submission, and no action from the operator.

Auto-detection

When an exploit is confirmed, the registry identifies every Cover Token with an active position in the affected market and includes it in the incident. Validation runs against on-chain state, not against anything the operator files, so a covered operator cannot miss a payout by failing to act.

The Cover Token is the only artifact in the flow. It carries the evidence that coverage is enabled on the vault and tracks what remains after each payout. A partial payout leaves the rest in force for the period.

Incident lifecycle

A covered incident moves through six phases. Partner service-level targets set the pace, not protocol deadlines. The backstop is the period boundary: an incident unresolved by the end of the following period expires with no payout.

1. Exploit Confirmed. Monitoring detects a potential exploit. The curator opens the incident on-chain. The curator here is the same role introduced in Introduction → Who participates: the entity that designs vault strategies also performs incident curation for the protocol. This freezes the exposed Cover Token set and pauses vault deployments.

2. Exploit Report. An independent security partner publishes an exploit report on-chain. Assessment cannot begin until it is recorded. Target: 48h.

3. Assessment. The protocol calculates a proposed loss schedule through automated check of Cover Tokens with exploited market exposure. The Risk Consortium validates it. Assessors confirm the amounts rather than recomputing them. Approval requires a 3-of-5 quorum. Period expiry is the backstop. Target: 24h protocol report and 72h validation.

4. Liquidation. Approval triggers settlement automatically. The First-Loss Buffer absorbs the first tranche. If exhausted, the vault is slashed pro-rata for the remainder, and slashed assets are converted to stablecoins.

5. Payout. Proceeds go to each Cover Token's beneficiary address, pro-rata to approved loss. If proceeds fall short, every beneficiary takes the same proportional reduction.

6. Closed. Distribution completes and the incident is finalised.

Deployments pause when an incident opens, so capital entering afterward does not absorb its loss. Deployments reopen when the slash settles, the incident is canceled, or the next period begins. Withdrawals and cover settlement are unaffected.

Stage	Activity	Owner
Detection	Potential exploit flagged	Monitoring infrastructure
Confirmation	Incident opened and exposed Cover Tokens frozen	Curator
Reporting	Exploit report published. Target: 48h	Independent security partner
Loss assessment	Loss schedule calculated. Target: 24h	Curator
Validation	Approve or Deny with a 3-of-5 quorum, with written rationale. Target: 72h	Risk Consortium
Settlement	Buffer draw, pro-rata slash, and liquidation	Liquidation service
Payout	Pro-rata distribution to beneficiaries	Firelight Foundation
Recovery	Recovered assets returned to stakers after settlement	Firelight Foundation

See How Claims Are Assessed for the validation model and Claims Liquidation for settlement mechanics.

Where to read next

• How Claims Are Assessed covers the consortium's process.

• Claims Liquidation goes deeper on the liquidation mechanics.