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.
Firelight Coverage is not insurance. It is a protocol-based coverage mechanism that a program operator elects on the vault they run.
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 Foundation stewards the protocol.
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 Foundation
Foundation 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 Foundation 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:
First-Loss Buffer: the protocol-owned stablecoin reserve draws down first.
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 Foundation's role
The Firelight Foundation 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:
Stakers deploy FXRP into the Firelight Protocol.
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.
An incident occurs on the covered protocol.
An independent security partner files an exploit report.
The Risk Consortium votes on validity and loss amount. An Approve vote triggers a slash.
The First-Loss Buffer absorbs the first tranche of loss. Any remainder is met by slashed collateral from the Firelight Vault.
Slashed assets are converted to stablecoins by the Liquidation service.
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 and the incident-lifecycle flow lives in Claims Process.
Where to read next
Core Concepts introduces the risk framework, coverage types, and period mechanics in more depth.
For Program Operators expands the program operator side.
For Stakers expands the supply side.
Risk Consortium details validation.
Last updated