> 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/resources/faq.md). # 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](/for-program-operators/cover-tokens.md). ### 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](/core-concepts/coverage-types.md) 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](/core-concepts/coverage-types.md). 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](/resources/links-and-contact.md). 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](/for-program-operators/supported-protocols-and-markets.md). ### 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](/for-program-operators/pricing.md). #### 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](/for-program-operators/claims-process.md). #### 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 the unstaking window? No. Your stXRP is redeemed when the unstake is initiated, and emissions accrual stops at that moment. The underlying becomes withdrawable at the end of the period following the one in which you unstaked. #### **Can my position be slashed while it is unstaking?** Yes, in two ways. For the remainder of the period in which you unstake, your capital is still backing coverage: a new exploit incident in that period slashes it pro-rata alongside active positions. The following period is a reconciliation window: your capital is not exposed to new incidents, but a slash attributed to a period in which it was still backing coverage still applies to the pending withdrawal. Unstaking removes your capital from the next period's coverage capacity, but not from this exposure. ### Risk Consortium #### Who validates incidents? An independent Risk Consortium of five confirmed members: Hypernative, Cyfrin, Credora, GFX Labs, and Native. See [Risk Consortium](/risk-consortium.md). #### 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. --- # 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/resources/faq.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.