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.
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:
Reads the full report.
Confirms the incident occurred during an active coverage period for at least one Cover Token.
Validates that the affected protocol and market are on the schedule of covered items.
Classifies the incident against the categories in Coverage Types.
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. 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:
The result is published on-chain.
If approved, the protocol generates a slash instruction and the incident enters the payout waterfall (see Claims Process).
Every auto-included Cover Token exposed to the incident is settled according to the payout calculation.
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 for the scope and responsibilities that frame this procedure.
Claims Process for the program operator-side view.
Last updated