> 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.md). # Introduction This section introduces Firelight Coverage: what it is, who participates, the problem it addresses, and a one-page walkthrough from cover enablement through payout. ### What is Firelight Coverage Firelight Coverage is an on-chain protection layer for DeFi positions. A **program operator** running a vault for end users can enable cover made available through Firelight on that vault. If a qualifying incident occurs, the protocol can pay the program operator in stablecoins, and the operator may distribute that payout to affected depositors under the vault's terms. Cover is backed by deployed capital in the Firelight protocol. Stakers stake FXRP into Firelight and earn base rate emissions plus protocol rewards tied to coverage activity. Incidents are validated by an independent **Risk Consortium** against published coverage criteria. The **Firelight Network** stewards the protocol and holds protocol treasury. {% hint style="info" %} Firelight Coverage is not insurance. It does not create a contract of insurance with Firelight, the Network, or a vault depositor. It is a protocol-based coverage mechanism that a program operator elects on the vault they run. {% endhint %} ### Who participates Firelight has a layered participant model: * **Stakers** supply backing capital. Staking is **permissionless**, and anyone can stake FXRP and earn a share of network emissions. * **Program operators** enable cover on the vaults they run. They hold the on-chain Cover Token, receive payouts directly and programmatically from the protocol, and may distribute payouts to their vault's depositors subject to the vault's terms. In the MVP, enabling cover is **permissioned to institutions** that complete onboarding (AML/sanctions screening and eligibility checks). * **End users** deposit into a program operator's vault. They benefit from any payout the program operator distributes under that vault's terms and conditions. They do not interact with Firelight directly. * **Curators** design the vault strategies that program operators offer. They can be the same entity as the program operator or a distinct partner. The curator role also extends to the incident lifecycle, where the protocol's designated curator opens incidents on-chain and prepares the proposed loss schedule for consortium validation (see [Claims Process](/for-program-operators/claims-process.md)). * **The Risk Consortium** is an independent group of confirmed security and risk specialists that validates incidents against coverage criteria and signals the protocol. * **The Firelight Network** stewards the protocol, holds protocol treasury, and engages the consortium and service providers. ### What this section covers * [The Problem](/introduction/the-problem.md) describes why DeFi needs a native coverage primitive and why this model is distinct from insurance. * [How Firelight Works](/introduction/how-firelight-works.md) walks through the personas and the full enablement-to-payout flow on a single page. ### Where Coverage fits in the protocol Coverage is the feature-complete phase of Firelight. It builds on the same staking and vault primitives used in Phase 1, extending them with: * A permissioned cover-enablement flow for institutional program operators * Network emissions from protocol revenue earned by stakers * An on-chain claims and payout process that pays the program operator directly * A risk and pricing framework that monitors risk components in real time to set capacity and premiums {% hint style="info" %} Until the feature-complete launch, coverage-related features described in this section are upcoming. Parameters and thresholds shown are target values and may be adjusted prior to launch. {% endhint %} --- # 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.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.