FAQ

Common questions about Firelight Coverage. Phase 1 reference material (FAQs, stXRP basics) has been merged into this documentation set; the Phase 1 pages are no longer maintained.

Coverage product

How is Firelight Coverage different from traditional risk-transfer products?

Risk-transfer claims with legacy carriers take weeks or months, depend on manual investigation of off-chain evidence, and assume static exposure. Firelight resolves incidents on-chain: an independent Risk Consortium validates incidents against published criteria, and valid coverage is included automatically without the program operator filing a claim.

Who can enable cover on a vault?

In the MVP, enabling cover is permissioned to institutions. The actor is the program operator, the institution running the underlying vault, who completes onboarding (AML/sanctions screening and eligibility checks) before they can enable cover on the vault they offer to end users. Staking, by contrast, is permissionless, anyone can stake FXRP to provide backing capital.

Who actually receives the payout?

The protocol releases payouts to the beneficiary address recorded on the Cover Token. In MVP, that address is expected to be controlled by the program operator that enabled cover. The operator may then pass proceeds through to end users under the vault's terms. End users do not receive funds directly from Firelight.

What does coverage pay out in?

Approved, audited stablecoins published on-chain. Each Cover Token records a preferred payout stablecoin. If that currency lacks liquidity at settlement, the protocol falls back through the supported set and may split across currencies. The full entitled amount is delivered regardless of currency mix.

Can coverage be cancelled mid-period?

No. Coverage is paid upfront for the 30-day period and runs to expiry. Program operators who do not want to continue simply do not renew at the next period boundary.

What is a Cover Token?

A Cover Token is an on-chain ERC-721 token representing an active coverage position, not an NFT collectible. It encodes the covered markets, coverage amount, rate, premium, and period. See Cover Tokens.

Eligibility and scope

What kinds of losses are covered?

Smart contract exploits, oracle failures, governance exploits, bad-debt from mechanism failure, mechanism-driven depegs, and redemption failures. See Coverage Types for the high-level categories.

What is not covered?

Normal market volatility, MEV, structural design flaws, rug pulls, insider theft, user error, phishing, regulatory seizure, risks disclosed at inception, depegs where redemption works as designed, legitimate governance outcomes, force majeure, losses outside the covered period, and losses on markets not listed in the cover terms. The summary is in Coverage Types. The authoritative, complete exclusions list lives in the full cover terms.

Where do I find the full cover terms?

The complete, legally binding cover terms are published to IPFS and linked from Links & Contact. Each Cover Token also references the applicable terms document via its termsURI.

Which protocols are on the approved list?

The approved list is published in the on-chain Cover Registry and updated each period. At launch it focuses on major EVM lending markets, DEX liquidity positions, and curated strategies. See Supported Protocols and Markets.

Pricing

How are premiums calculated?

Premiums reflect Firelight's live view of a market's risk. The protocol monitors risk components (blockchain, protocol, asset, strategy) in real time. Higher monitored risk means a higher rate. A program operator's premium is the coverage-weighted blend of the per-market rates. See Pricing.

Do premiums change within a period?

No. Premiums are fixed for the 30-day period of active coverage. The Cover Registry refreshes rates at each period boundary, which applies to newly enabled cover and renewals at that boundary.

Claims

Do I need to file a claim?

No. Firelight uses auto-inclusion: when a covered incident is detected and confirmed, the protocol identifies every active Cover Token exposed to it and includes the valid ones automatically. You cannot miss a payout by failing to file within a window.

How does a covered incident become a payout?

Monitoring and an independent security partner confirm and report the incident. The protocol auto-includes exposed coverage. The Risk Consortium validates and votes (3-of-5 quorum). Validated losses are then paid through the waterfall. See Claims Process.

What happens if only part of my coverage is used?

Payouts are bounded by the protocol's total payout capacity at settlement, and pro-rated if a single incident exceeds it. The Cover Token tracks remaining cover, and you stay covered for the remainder of declared markets through the rest of the period.

Is there a deadline for incidents to resolve?

Yes. An incident that remains unresolved by the end of the period following the one in which it was confirmed expires with no payout. Partner service-level targets (48h exploit report, 24h loss schedule, 72h validation) are designed to resolve incidents well inside this backstop.

Staking and capital

What am I exposed to as a staker?

Once coverage is live on Flare, all staked capital in the vault backs coverage and is slashable. Slashing only happens if a validated claim exhausts the First-Loss Buffer. Even then it is pro-rata across all positions. In exchange, stakers earn protocol-related rewards alongside the protocol's base rate emissions.

Is there a protected vs unprotected option?

No. The protected/unprotected distinction has been removed. All capital deployed in the protocol is utilized to enable cover.

How is my position affected by a claim payout?

Only if a validated claim exhausts the First-Loss Buffer. At that point, slashing applies pro-rata across all positions in the vault. Smaller incidents do not reach staker collateral.

Do I still earn base rate emissions while my withdrawal is in cooldown?

No. emissions accrual stops at the moment a withdrawal is initiated. Note that the unstaking cooldown for the coverage vault is longer than the cooldown Firelight launched with in Phase 1.

Risk Consortium

Who validates incidents?

An independent Risk Consortium of five confirmed members: Hypernative, Cyfrin, Credora, GFX Labs, and Native. See Risk Consortium.

How are conflicts handled?

A member with a conflict in a given incident declares a non-vote and steps out for that incident. Non-votes are recorded on-chain for transparency.

Can the Foundation override the consortium?

No. The consortium's vote is binding subject to the 3-of-5 quorum and approval threshold. The Foundation engages members but does not direct their decisions.