> 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/introduction/how-firelight-works.md).
# How Firelight Works
This page walks through the full Firelight Coverage flow on a single page: who the participants are, how capital and cover come together, and how a covered incident becomes a payout that reaches end users.
{% hint style="info" %}
Firelight Coverage is not insurance. It is a protocol-based coverage mechanism that a program operator elects on the vault they run.
{% endhint %}
### The participants
Firelight has a layered participant model. Stakers back cover. Program operators elect cover on the vaults they run. End users deposit into those vaults and may benefit through the operator. The Risk Consortium validates incidents. The Firelight Network stewards the protocol.
| Role | Access | What they do | What they receive |
| ---------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Stakers | Permissionless | Stake FXRP into the Firelight protocol | Receive a vault-share token (stXRP) , protocol emissions and protocol-related rewards |
| Program operators | Permissioned to institutions (MVP) | Elect cover on a vault they run for a 30-day period | A Cover Token and automatic payout to the token's beneficiary address |
| End users (vault depositors) | Determined by the operator's vault | Deposit into a program operator's vault | Protections on deposits, subject to coverage criteria and operator terms |
| Curators | Commercial arrangement | Design strategies in the underlying vault | Fees from the vault strategies they design, on terms agreed with the operator |
| Risk Consortium | Confirmed members | Validate incidents against coverage criteria and signal the protocol by on-chain vote | Consortium compensation |
| Firelight Network | Network entity | Steward Firelight Protocol, hold protocol treasury, and engage service providers | n/a |
Staking is open to anyone. Enabling cover is restricted to onboarded institutions during the MVP. The Risk Consortium is independent of the Network and commercial counterparties. End users never interact with Firelight directly. They deposit into the program operator's vault, and any flow of proceeds to them is determined by the program operator's terms.
### End-to-end flow
#### 1. Capital deployment
A staker stakes FXRP into the Firelight protocol. The deployment then moves through screening and activation. Rewards begin only after the deployment becomes active.
#### 2. Capacity publication
The protocol publishes per-market coverage capacity and premium rates in the protocol dashboard. Parameters refresh each 30-day period. Each market is defined by a combination of chain, protocol, and market.
#### 3. Cover enablement
An onboarded program operator selects one or more approved markets, specifies a total coverage amount, and receives a quote based on currently available limits by protocol. The program operator pays the premium upfront for the 30-day period. On confirmation, the protocol issues an on-chain **Cover Token** (an ERC-721 token) to the program operator's address. The token encodes the covered markets, coverage amount, premium, rate, and coverage period.
#### 4. Capital matching at the period boundary
At each period boundary, the matching engine allocates capacity:
* Renewals from existing coverage holders are processed first. If renewal demand exceeds capacity, allocations are pro-rated by each holder's prior-period coverage amount.
* Remaining capacity is allocated to new orders, pro-rated by requested amount if demand exceeds capacity.
* Unmatched or partially matched orders receive proportional refunds.
Matched coverage becomes active for the new period.
#### 5. Staker rewards
Settled premiums and protocol emissions support staker rewards: premiums and base rate boosts compound into the vault's redemption value, while additional protocol reward boosts are distributed to stakers.
#### 6. Incident detection and auto-inclusion
When an exploit or covered incident occurs — for example, a smart-contract exploit, an oracle failure or manipulation, a governance exploit, mechanism-driven bad debt, a redemption failure, or a mechanism-driven depeg — monitoring infrastructure and an independent security partner confirm and report it on-chain. **There is no separate claims-submission step.** The protocol identifies every active Cover Token exposed to the incident and automatically includes the valid ones in the incident's claim set. Program operators do not need to file or chase anything.
#### 7. Consortium validation
The Risk Consortium reviews the incident report, validates it against the published coverage criteria, and votes. A quorum of **3-of-5 confirmed members** is required for a binding decision. Members with a conflict declare a non-vote. The consortium signals the protocol by way of an on-chain vote. The protocol acts on that signal automatically.
#### 8. Payout waterfall
If the consortium signals Approve, the loss is absorbed in the following order:
1. **First-Loss Buffer:** the protocol-owned stablecoin reserve draws down first.
2. **Vault slashing:** any remaining loss is allocated pro-rata across staker positions.
Slashed collateral is routed to a liquidation process that converts it into the program operator's preferred payout stablecoin. Execution sizing adjusts with claim size, from on-exchange execution for smaller claims to syndicated OTC for the largest.
#### 9. Settlement to the beneficiary address
Firelight Protocol releases the payout to the beneficiary address recorded on the **Cover Token**. In practice, that address is expected to be program operator-controlled during MVP.
#### 10. Flow of proceeds to end users
The program operator may pass the payout through to the **end users** whose positions in the underlying vault were exposed to the incident, subject to the operator's vault terms. Firelight's role ends at step 9. Any flow of proceeds to end users is the operator's responsibility, not Firelight's. Any assets recovered after payout are subject to a recovery bounty paid to the Risk Consortium and returned to the loss layers in reverse order of absorption.
### The Network's role
The Firelight Network is the steward of Firelight Protocol. It holds protocol-owned treasury, including the First-Loss Buffer, and engages the Risk Consortium and service providers. It does not hold end-user funds, control end-user payouts, act as an insurer, or direct consortium decisions on incident confirmation.
### Visual summary
The unified-flow diagram shows the full Firelight lifecycle from staker deployment through stablecoin payout. In short:
1. **Stakers** deploy FXRP into the **Firelight Protocol**.
2. A **Program Operator** enables cover for the vault they run. The protocol issues a **Cover Token** for the period. Premiums flow back to the Firelight Vault.
3. An **incident** occurs on the covered protocol.
4. An independent security partner files an **exploit report**.
5. The **Risk Consortium** votes on validity and loss amount. An Approve vote triggers a slash.
6. The **First-Loss Buffer** absorbs the first tranche of loss. Any remainder is met by **slashed collateral** from the Firelight Vault.
7. Slashed assets are **converted to stablecoins** by the Liquidation service.
8. The **stablecoin payout** is released to the **Cover Token beneficiary address**, which may then pass proceeds through to end users under the operator's vault terms.
The companion commercial flow lives in [How Coverage Works](/for-program-operators/how-coverage-works.md) and the incident-lifecycle flow lives in [Claims Process](/for-program-operators/claims-process.md).
### Where to read next
* [Core Concepts](/core-concepts.md) introduces the risk framework, coverage types, and period mechanics in more depth.
* [For Program Operators](/for-program-operators.md) expands the program operator side.
* [For Stakers](/for-stakers.md) expands the supply side.
* [Risk Consortium](/risk-consortium.md) details validation.
---
# 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/introduction/how-firelight-works.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.