> For the complete documentation index, see [llms.txt](https://docs.firelight.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.firelight.finance/for-program-operators/claims-process.md).
# 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](/introduction.md): 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 Network |
| Recovery | Recovered assets returned to stakers after settlement | Firelight Network |
See [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed.md) for the validation model and [Claims Liquidation](/protocol-architecture/claims-liquidation.md) for settlement mechanics.
### Where to read next
* [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed.md) covers the consortium's process.
* [Claims Liquidation](/protocol-architecture/claims-liquidation.md) goes deeper on the liquidation mechanics.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.firelight.finance/for-program-operators/claims-process.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.