> 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/risk-consortium/how-claims-are-assessed.md). # How Claims Are Assessed This page walks through how the Risk Consortium assesses a covered incident. Because Firelight uses auto-inclusion, there is no program operator-submitted claim to process. The consortium validates the incident itself, and the protocol applies the outcome to every Cover Token already exposed to it. ### Position in the overall flow The consortium owns the validation and vote stages of the incident lifecycle. The other stages, detection, confirmation, reporting, settlement, are owned by monitoring infrastructure, the independent security partner, and the liquidation service. | Stage | Activity | | ---------- | --------------------------------------------- | | Validation | Scope review and conflict declarations | | Vote | Binding Approve/Deny determination | | Recovery | Recovery-bounty participation (if applicable) | ### Validation On receipt of an exploit report from the independent security partner, each member: 1. Reads the full report. 2. Confirms the incident occurred during an active coverage period for at least one Cover Token. 3. Validates that the affected protocol and market are on the schedule of covered items. 4. Classifies the incident against the categories in [Coverage Types](/core-concepts/coverage-types.md). 5. Declares any conflicts. Validation does not involve re-running the security partner's analysis from scratch. The consortium's job is to apply coverage terms, not to duplicate forensic work. ### The vote Following validation, the consortium votes. A vote has three elements: * **A binary decision** (Approve or Deny) on whether the incident qualifies as a covered claim. * **A written rationale** recording the member's reasoning and the key parameters: exploit timestamp, affected protocol, impacted assets, total value exploited, and total value covered. * **A quorum check** against the consortium's configured threshold. Members who declared a conflict submit a non-vote, which does not count for or against the threshold. #### Quorum and threshold Members vote Approve or Deny. A decision requires a **3-of-5 quorum**. The vote runs against a short service-level window to support fast payout while leaving room for diligence. If quorum is not met within the window, the vote is briefly extended. If still not met, no binding decision is produced in that window. The hard backstop is the period boundary: an incident left unresolved by the end of the following period expires with no payout. ### Conflicts and non-votes A conflict exists when a member has a direct or indirect interest in the outcome, for example, being an employee, advisor, or investor in the exploited protocol, or having produced an assessment that materially influenced the coverage decision being reviewed. The member declares a non-vote, which is recorded on-chain for transparency, and does not participate in that incident's vote. ### What counts as a qualifying incident Members apply the coverage categories and boundary rules in [Coverage Types](/core-concepts/coverage-types.md). The recurring test is whether a mechanism malfunctioned (qualifying) or behaved as designed (not qualifying): a flash-loan governance exploit qualifies, while legitimate vote accumulation does not. An oracle manipulation qualifies, while normal cross-exchange arbitrage does not. A depeg from a broken redemption mechanism qualifies, while redemption gates working as designed do not. ### Post-vote flow Once the vote closes: 1. The result is published on-chain. 2. If approved, the protocol generates a slash instruction and the incident enters the payout waterfall (see [Claims Process](/for-program-operators/claims-process.md)). 3. Every auto-included Cover Token exposed to the incident is settled according to the payout calculation. 4. If denied, no payout occurs and active Cover Tokens remain in force for the remainder of their periods. ### Recovery participation Assets recovered after payout (through white-hat negotiation or law-enforcement cooperation) flow back through the waterfall in reverse order of absorption, with a recovery bounty paid to members who actively contributed to the recovery. ### Where to read next * [Role of the Consortium](/risk-consortium/role-of-the-consortium.md) for the scope and responsibilities that frame this procedure. * [Claims Process](/for-program-operators/claims-process.md) for the program operator-side view. --- # 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/risk-consortium/how-claims-are-assessed.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.