# Welcome to Firelight Protocol Firelight Coverage adds an on-chain protection layer for DeFi positions. Program operators can elect cover on the vaults they run. Stakers supply backing capital. The Risk Consortium validates incidents against published coverage criteria and signals the protocol. The protocol pays program operators, who may distribute payouts to affected depositors under their vault terms. {% hint style="warning" %} 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 program operators elect on the vaults they run. {% endhint %} ### Who participates | Participant | What they do | Access | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | **Stakers** | Stake FXRP to back cover and earn protocol rewards | Permissionless | | **Program operators** | Elect to enable cover on the vaults they run. Hold the on-chain Cover Token. Determine distribution criteria for payouts to their vault's end users | Permissioned to institutions in the MVP | | **End users** (vault depositors) | Deposit into a program operator's vault. Inherit certain protections on deposits through the operator's election of cover and distribution criteria | Set by each operator's vault | | **Curators** | Design the vault strategies that program operators offer | Commercial arrangement | | **Risk Consortium** | Independently validate incidents against coverage criteria and signal the protocol | Confirmed members | | **Firelight Network** | Stewards the protocol and holds protocol treasury | Network entity | End users do not interact with Firelight directly. They deposit into a program operator's vault. Any payout they receive is governed by that vault's terms, not by Firelight. ### Phase 1 and Phase 2 Firelight launched in **Phase 1** as a single-asset staking protocol. stXRP was backed by XRP through FXRP on Flare and deployed into Firelight during the Launch Phase. **Phase 2 (Coverage)** extends that base with an on-chain coverage protocol backed by the same staked capital. This documentation focuses on Phase 2. Useful Phase 1 reference material remains here, including FAssets, FXRP, and stXRP definitions, launch-vault audits, and the onboarding flow for new stakers. ### Start here * [Introduction](/introduction) explains what Firelight Coverage is, the problem it solves, who participates, and how the full flow works. * [Core Concepts](/core-concepts) covers the risk framework, coverage types, period mechanics, and vault architecture. ### For different audiences * Enabling cover on a vault you run: [For Program Operators](/for-program-operators) * Staking FXRP to back coverage: [For Stakers](/for-stakers) * Assessing incidents as an independent reviewer: [Risk Consortium](/risk-consortium) ### Reference * [Risk and Pricing Model](/risk-and-pricing-model) explains how risk components are monitored in real time to drive pricing, capital adequacy, and diversification. * [Protocol Architecture](/protocol-architecture) describes the protocol contracts and service layers that support coverage. * [Resources](/resources) contains the FAQ, glossary, security information, and key links. # 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)). * **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) describes why DeFi needs a native coverage primitive and why this model is distinct from insurance. * [How Firelight Works](/introduction/how-firelight-works) 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 %} # The Problem DeFi has grown into a multi-hundred-billion-dollar market, but the risks behind it remain largely uncovered. Users and institutions deploy capital into smart contracts every day without a reliable way to isolate and transfer the downside of a failure. They also do not enter into a traditional insurance contract when they deposit into a vault. ### DeFi risk is structural, not occasional Losses in DeFi do not come from a single cause. They come from a stack of interdependent layers: * **Blockchain risk:** consensus failures, validator issues, reorgs, and network-level incidents * **Protocol risk:** smart contract bugs, governance exploits, oracle manipulation, upgradeable proxy errors * **Asset risk:** depegs, thin liquidity, price collapses affecting collateral * **Strategy risk:** leveraged or composed positions where one failure cascades into others A failure at any lower layer propagates upward. A blockchain halt stops every protocol on that chain. An oracle manipulation can cascade into bad debt across multiple lending markets. Users rarely have a mechanism to isolate or transfer these risks. ### Traditional risk-transfer products do not fit Legacy risk-transfer products were not built for on-chain risk: * **Speed:** DeFi exploits resolve in hours. Traditional claims take months. * **Verifiability:** exploit evidence is on-chain and auditable in real time, but legacy carriers depend on manual investigation. * **Composability:** DeFi positions move across protocols every period. Traditional policies assume static exposure. * **Eligibility:** most institutional carriers do not back crypto-native risks at all. The result is a market where capital is deployed without coverage, where participants self-cover implicitly, and where a single exploit can wipe out returns across a whole portfolio. ### What a native coverage primitive needs DeFi needs coverage built into the product stack itself, not bolted on as a separate policy purchase. A native coverage primitive must be: * **Built into the product.** A program operator elects cover on the vault they run. * **On-chain and programmatic.** Coverage criteria, evidence, and payouts are applied by protocol rules. * **Transparent.** Capacity, premiums, and risk parameters are publicly visible. * **Fast.** Claims resolve in days, not months, with payouts in stablecoins. * **Composable.** Coverage integrates into vaults, lending markets, and structured products without custom wrappers. * **Reward-aligned.** Capital that backs coverage through staking is rewarded with protocol emissions linked to protocol activity. * **Distinct from insurance.** The mechanism transfers and isolates risk through protocol design. It does not create a contract of insurance between Firelight and the depositor. Firelight Coverage is built to meet these requirements. The rest of this documentation explains how. ### Next See [How Firelight Works](/introduction/how-firelight-works) for a one-page walkthrough of the full coverage flow. # 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) and the incident-lifecycle flow lives in [Claims Process](/for-program-operators/claims-process). ### Where to read next * [Core Concepts](/core-concepts) introduces the risk framework, coverage types, and period mechanics in more depth. * [For Program Operators](/for-program-operators) expands the program operator side. * [For Stakers](/for-stakers) expands the supply side. * [Risk Consortium](/risk-consortium) details validation. # Core Concepts This section introduces the concepts that underpin Firelight Coverage: the risk framework, the specific risks covered, how time is structured around periods, and how the vault holds and deploys capital. ### What you'll find here * [Risk Pricing Framework](/core-concepts/risk-pricing-framework) describes, at a high level, how Firelight monitors a set of risk components in real time to produce a risk view for every coverage market. * [Coverage Types](/core-concepts/coverage-types) lists the technical and economic risk categories that coverage addresses and flags what is excluded. * [Periods and Coverage Cycles](/core-concepts/periods-and-coverage-cycles) explains the 30-day coverage period and how capacity, pricing, and renewals align to period boundaries. * [Vault Architecture](/core-concepts/vault-architecture) covers the stXRP vault that holds staked collateral and how it backs coverage. ### How this section connects to the rest These concepts appear throughout the program operator and capital-provider sections. A program operator reading [Pricing](/for-program-operators/pricing) will encounter the risk framework again. A capital provider reading [Risk and Exposure](/for-stakers/risk-and-exposure) will see period mechanics in action. Starting here gives both audiences the shared vocabulary the rest of the docs assume. # Risk Pricing Framework Firelight prices coverage by monitoring a set of risk parameters for every approved market and updating its view of those components in real time. This page gives a high-level picture of how that works. It is intentionally non-mathematical.\ The detailed methodology lives in the [Risk and Pricing Model](/core-concepts/risk-pricing-framework) reference. ### Two views of risk Firelight quantifies all risk parameters in two separate views and prices them independently: | View | What it captures | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Economic** | Market-driven risk: leverage, liquidity stress, collateral fragility, liquidation failure, and structural relationships between collateral and the loan tokens it backs. | | **Technical** | Code and infrastructure driven risk: smart-contract bugs, oracle and integration fragility, upgrade patterns, and chain-level settlement behavior. | The two views are kept separate on purpose. A market can be economically safe but technically weak, or technically strong but economically fragile, and the pricing engine reflects both. ### Economic risk: two components The economic view itself is built from two complementary components: * **A near-term bad-debt view.** For each lending market, the protocol monitors how likely a bad-debt incident is over the next 30 days and, if such an incident occurs, how severe the loss would be. This is the day-to-day market-condition view of economic risk. * **A structural graph overlay.** The overlay watches relationships between tokens. For example, collateral assets and the loan tokens they back, or the reserves of stablecoins and LSTs. For example, lender liquidity being trapped when borrowers consume available liquidity, or fragile collateral draining liquidity from the loan tokens above it. The bad-debt view and the graph overlay add up to the market's economic risk for pricing purposes. ### Technical risk The technical view scores the protocol and chain's implementation separately from market conditions. It feeds its own portfolio-level expected-loss view (see [Technical Scoring](/risk-and-pricing-model/technical-scoring)). \ Critical technical findings (a risky code upgrade, an unsafe access control pattern) can remove a market from coverage even when the economic view is clean. ### Risk is layered, and monitored continuously Within each view, signals are organized across the same four layers and refreshed continuously from on-chain data and external feeds: | Layer | What Firelight watches | | ---------- | ---------------------------------------------------------------------------------------------- | | Blockchain | Network health, finality, validator decentralization, incident history | | Protocol | Code comple, Audit status, exploit history, oracle dependencies, governance and admin controls | | Asset | Price volatility, liquidity depth, depeg behavior, holder concentration | | Strategy | Composition, leverage, liquidation parameters, correlated exposure | **The result is a live risk view per market rather than a one-time score.** ### From monitoring to pricing The real-time risk view drives three things: * **Eligibility.** Markets whose monitored risk is too high, or where a critical signal fires (an active exploit, a lapsed audit, a depeg with broken redemption), are not offered coverage. * **Premium rate.** A higher monitored risk level maps to a higher premium. The premium reflects the protocol's expected cost of covering the market plus the cost of the capital backing it, across both the economic and technical views. * **Capacity.** The risk view, combined with portfolio diversification, sets how much coverage the protocol will write on a given market (see [Capital Adequacy](/risk-and-pricing-model/capital-adequacy)). Pricing is not static. As the monitored views change between periods, the inputs to the next period's published rate change with them. The premium is paid by the program operator when it elects cover on a vault. End users do not pay Firelight directly. A program operator may reflect coverage cost in the product economics of its vault. ### A composite view for display Alongside the economic and technical views, Firelight maintains a **composite risk score** that blends the two into a single view per market for ranking and display. The composite is a presentation aid. It does not replace the underlying split that pricing actually uses. ### What the protocol publishes For each approved market, the protocol publishes a base premium rate and the available limit by protocol to the Cover Registry, refreshed on a 30-day cadence. Within a period the published rate is fixed for program operators. Between periods it can move as the monitored views update. {% hint style="info" %} Detailed mechanics, how signals combine, severity assumptions, the graph overlay's specific paths, and capital adequacy math, are covered in the [Risk and Pricing Model](/risk-and-pricing-model) section and are under active calibration. Published values in the Cover Registry always take precedence. {% endhint %} ### Where to read next * [Coverage Types](/core-concepts/coverage-types) lists the specific risk categories that the framework prices. * [Pricing](/for-program-operators/pricing) shows how a program operator's quote is built from the published rate. * [Risk and Pricing Model](/risk-and-pricing-model) goes deeper for readers who want the methodology. # Coverage Types Firelight Coverage addresses two broad categories of DeFi risk: technical failures in underlying code and infrastructure, and economic failures in protocol mechanisms. Both require a clear trigger and verifiable on-chain evidence. Within the economic category, coverage spans both direct bad-debt incidents on a covered market and structural impairments transmitted through relationships between collateral assets and the loan tokens they back. The risk framework treats these as a single economic view but tracks them through separate signals. See [Economic Model](/risk-and-pricing-model/economic-model). This page describes the categories at a high level. The full, legally binding cover terms, including precise definitions, conditions, and the complete exclusions list, are published separately and linked from [Resources](/resources). ### Covered technical risks Technical risks stem from failures in smart contract code, oracle infrastructure, and governance mechanisms. | Risk category | Description | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Smart contract exploits | Losses from bugs, logic errors, or vulnerabilities such as reentrancy, access-control failures, and upgradeable-proxy implementation errors | | Oracle failures | Losses from oracle malfunction or manipulation, including price-feed manipulation, stale-data exploitation, and data-source compromise | | Governance exploits | Losses from governance mechanism failures, including malicious upgrade execution and flash-loan-enabled voting | ### Covered economic risks Economic risks stem from protocol mechanisms failing under stress, rather than from normal market conditions. | Risk category | Description | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Bad-debt from mechanism failure | Protocol bad-debt arising from mechanism malfunction, including liquidation mechanisms that fail to function as designed | | Depegs caused by mechanism failure | Pegged-asset deviations caused by a redemption or stabilization mechanism breaking | | Redemption failures | Losses when a protocol cannot honor withdrawals due to design flaws | {% hint style="warning" %} Economic-risk coverage carries a duty to mitigate. Once a program operator becomes aware of, or circumstances indicate the likelihood of, a covered economic incident, they must take reasonable steps to limit losses, such as attempting to withdraw, deleverage, or redeem. Payouts may be reduced to the extent losses could reasonably have been avoided. Full cover terms document linked from [Resources](/resources). That document will be published to IPFS closer to launch. {% endhint %} Economic-risk coverage is subject to sublimits set in the Coverage Schedule. Technical-risk coverage is written to the full scheduled limit. ### What is not covered Coverage is for failures of mechanism and code, not for ordinary market outcomes. At a high level, the following are excluded: normal market volatility, MEV, fundamental or structural design flaws, including undisclosed architectural weaknesses, rug pulls and insider theft, user error, including key loss and mis-signing, frontend and phishing attacks, regulatory seizure, risks disclosed and accepted at inception, depegs where redemption works as designed, legitimate governance outcomes, force majeure, exploits occurring before coverage inception or after expiry, and losses on markets not listed in the Cover Terms. {% hint style="info" %} The exclusions above are a summary. The authoritative, complete exclusions list and all boundary definitions live in the full cover terms document linked from [Resources](/resources). That document will be published to IPFS closer to launch. {% endhint %} ### Where to read next * [Risk Pricing Framework](/core-concepts/risk-pricing-framework) shows how these risks are monitored and priced. * [Claims Process](/for-program-operators/claims-process) walks through how a covered incident becomes a payout. # Periods and Coverage Cycles Firelight organizes time into fixed 30-day periods. Coverage, pricing, and capacity all align to period boundaries. This creates predictable cycles for program operators, stakers, and the Risk Consortium. ### Why periods Periods serve three purposes: * **Predictable pricing.** On-chain pricing parameters refresh every 30 days. Program operators know that a quote reflects the current period's published rates. * **Fair capacity allocation.** Coverage demand and supply are matched at period boundaries rather than continuously, which removes race conditions and enables pro-rata allocation under oversubscription. * **Bounded risk windows.** A 30-day coverage period limits the period during which a single set of coverage terms applies, reducing the protocol's exposure to stale assumptions. ### Period boundary sequence At each period boundary, the following happens in sequence: 1. **Pricing refresh.** The Cover Registry is updated with new base premium rates and available limits by protocol for each approved market. 2. **Capacity calculation.** The protocol computes available coverage capacity based on staked capital, the First-Loss Buffer, and effective leverage. 3. **Renewal matching.** Existing coverage holders who opted to renew are matched first. If renewal demand exceeds capacity, allocations are pro-rated by each holder's prior-period coverage amount. 4. **New order matching.** Remaining capacity is allocated to new orders, pro-rated by requested amount if demand exceeds capacity. 5. **Premium settlement.** Premiums for matched orders settle from the program operator's approved balance to the reward pool. Unmatched or partially matched orders receive proportional refunds. 6. **Coverage activation.** Matched coverage is issued as an on-chain coverage token and becomes active for the new period. Period settlement is **deterministic with respect to the period start timestamp**. Deployments and withdrawals submitted after a period has started do not affect the current period's settlement; they are picked up in the next period's capacity calculation. This makes each period's outcomes reproducible from its starting state. ### Mid-period mechanics Most operational activity happens at period boundaries, but certain components run continuously inside a period. #### Deployments Staker deployments do not wait for a period boundary, but they do move through screening before activation. Rewards begin only after the deployment becomes active. Deployments pause whenever an incident is opened, so capital entering after an incident does not absorb its loss. Deployments reopen when the slash settles, the incident is cancelled, or the next period begins. See [Claims Process](/for-program-operators/claims-process). #### Withdrawals An unstake can be initiated at any time, but the underlying only becomes withdrawable after the unstaking window: the remainder of the current period plus one full period. Periods are currently 1 day, so the unstaking window is currently 1 to 2 days. At the Feature-Complete launch, periods extend to 30-day cover periods to align with coverage obligations, so an unstake initiated at any point in a period becomes withdrawable at the end of the following period and the total effective unstaking window then ranges from 30-60 days. See [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals). #### Coverage scope within a period A Cover Token covers the markets declared when cover is enabled, up to the allocated amounts, for the full 30-day period. Coverage does not float between markets mid-period: a position that moves into a market not declared in the cover token is not covered for that allocation until the program operator renews with an updated declaration at the next boundary. ### Renewal vs. new order priority Renewals are processed before new orders at every boundary. This protects existing coverage holders from being displaced by incoming demand and gives program operators a reliable path to continuous coverage across periods. Within the renewal queue, allocation is pro-rata by prior-period coverage amount. First-come-first-served behavior is not used anywhere in the matching process. ### Why 30 days A 30-day period balances faster feedback on pricing and capacity against operational overhead and program operator friction, and aligns with institutional planning cycles. ### Where to read next * [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals) covers the supply-side mechanics of activation and unstaking. * [Pricing](/for-program-operators/pricing) explains how period-refreshed parameters produce a program operator quote. # Vault Architecture The Firelight vault holds the staked capital that backs coverage and issues the stXRP token that represents a staker's position. This page introduces the vault model at the MVP, where the single supported collateral is stXRP. ### ERC-4626 foundation The Firelight vault implements the ERC-4626 tokenized vault standard. This brings three benefits: * **Composability.** stXRP behaves like any other ERC-20, usable as collateral or liquidity across the broader DeFi ecosystem. * **Standardized accounting.** Deployments, redemptions, share-to-asset conversions, and period-based balances follow a well-understood interface that wallets, aggregators, and integrators can treat uniformly. * **Predictable integration.** Systems building on top of Firelight can rely on standard vault semantics rather than custom wrappers. The vault is non-custodial. The underlying assets remain in smart contracts, and stakers retain control through cryptographic means. ### FXRP as capital At the MVP, the Firelight vault accepts a single asset: **FXRP** (backed by XRP via Flare), this is already live in Phase 1. When FXRP is staked in the Firelight vault, stXRP is issued. Staking is permissionless, anyone can deploy FXRP. The vault: * Accepts FXRP deployments and tracks each staker's balance * Lets the staked collateral back active cover actively enabled on existing program vaults * Accrues base staking emissions from premiums into the position's redemption value over time Support for additional collateral assets is on the roadmap and would be introduced through governance in later versions. The documentation here describes the stXRP MVP. ### Slashing applies to staked capital When a validated claim exhausts the protocol's First-Loss Buffer, the remaining loss is met by slashing vault capital pro-rata across all positions. There is no separate "protected" or "unprotected" segment of the vault: once coverage is live, all staked capital in the protocol is part of the backing and is slashable. Stakers accept this exposure in exchange for the share of protocol emissions. Slashing mechanics and the loss waterfall are covered in [Risk and Exposure](/for-stakers/risk-and-exposure). ### First-Loss Buffer Alongside the staker vault, Firelight maintains a stablecoin First-Loss Buffer. The buffer is not a staker vault: it is protocol-owned capital that absorbs the first tranche of any validated claim, before any staker collateral is slashed. It sits between claims and the staked vault and protects stakers from the smallest loss incidents. The First-Loss Buffer feeds into the loss waterfall covered in [Claims Liquidation](/protocol-architecture/claims-liquidation). ### Vault lifecycle summary A typical deployment moves through these states: 1. A staker stakes FXRP into the protocol and receives stXRP. 2. The position is recorded and begins accruing rewards shortly after deployment. 3. Vault collateral counts toward available coverage capacity at the next period boundary. 4. If a validated claim's loss exceeds the First-Loss Buffer, the vault applies a pro-rata slash across all positions. 5. On unstaking, the stXRP is redeemed and the underlying FXRP becomes withdrawable at the end of the cover period following the one in which the unstake was initiated. ### Where to read next * [Staking Overview](/for-stakers/staking-overview) walks through the capital-provider side in detail. * [Risk and Exposure](/for-stakers/risk-and-exposure) covers slashing and the loss waterfall. # For Program Operators This section is for institutions enabling cover on a DeFi position: vault operators, structured-product providers, treasury managers, and partner protocols passing protection through to their own programs. {% hint style="info" %} In the MVP, enabling cover is **permissioned**. Program operators complete institutional onboarding (including AML/sanctions screening and eligibility checks) before they can request a quote or hold a Cover Token. Staking, by contrast, is permissionless. See [For Stakers](/for-stakers). {% endhint %} ### What you'll find here * [How Coverage Works](/for-program-operators/how-coverage-works) walks through the enablement flow end to end. * [Cover Tokens](/for-program-operators/cover-tokens) explains what you receive when cover is enabled: an ERC-7621 Cover Token that records your active coverage, and how claims are handled. * [Pricing](/for-program-operators/pricing) describes, at a high level, how premiums reflect the risk components Firelight monitors in real time. * [Claims Process](/for-program-operators/claims-process) details how a covered incident becomes a payout, with no claim-submission step required of the program operator. * [Supported Protocols and Markets](/for-program-operators/supported-protocols-and-markets) lists the markets eligible for coverage at launch. ### What you need to know before enabling cover Cover is enabled for a fixed 30-day period and cannot be cancelled mid-period. Premium is paid upfront. You receive an on-chain Cover Token representing your active coverage for that period, which you hold until expiry. When a payout is triggered, you receive the proceeds as the holder of the on-chain Cover Token and pass them through to depositors in the underlying vault under the vault's terms. Coverage applies only to markets you explicitly schedule when cover is enabled. If your strategy moves into a non-declared market during the period, that allocation is uncovered until you renew with an updated declaration. See [Periods and Coverage Cycles](/core-concepts/periods-and-coverage-cycles). ### Typical program operator journey 1. Complete institutional onboarding (one time). 2. Review the approved markets and current available limits in the Cover Registry. 3. Request a quote specifying markets and coverage amounts. 4. Approve premium spending from a prefunded wallet. 5. At the next period boundary, the matching engine allocates capacity and settles premium. 6. Coverage activates and the Cover Token is issued to your address. 7. If a covered incident occurs, valid coverage is included automatically, no claim filing required. # How Coverage Works This page walks through the program operator's side of the protocol from quote to active coverage. For the end-to-end flow including claims and payout, see [How Firelight Works](/introduction/how-firelight-works). ### What enabling cover gives you Enabling cover creates a 30-day right to receive a stablecoin payout if one of the incidents listed in [Coverage Types](/core-concepts/coverage-types) occurs on a market you have explicitly scheduled. Coverage is: * **Market-specific.** A Cover Token lists the chain, protocol, and market combinations it covers (with an optional pool identifier for DEX positions). Losses outside those combinations are not paid. * **Capped.** Each coverage position has a total coverage amount and per-market sub-limits. Payouts are bounded by the protocol's total payout capacity at settlement. * **Time-bounded.** Coverage runs for the 30-day period for which it was enabled. Renewal is a separate action. ### The quote request An onboarded program operator (or a curator acting on their behalf) specifies: | Input | Description | | --------------- | ----------------------------------------------------------------------- | | Markets | One or more approved chain + protocol + market combinations | | Coverage amount | The total USD-denominated coverage desired, with per-market allocations | | Duration | Always 30 days (one period) at the feature-complete launch | The protocol returns a quote with: * Per-market premium rates * A blended premium rate across the bundle * Total premium due for the 30-day period * Available limits per market (capacity available by protocol) * Quote validity (tied to the next pricing refresh) Quotes are framed around the **available limit by protocol**, how much coverage capacity remains for that protocol this period, rather than a position-specific backing negotiation. ### Paying the premium Premium is paid upfront for the full 30-day period via an approval-based flow: 1. The program operator prefunds the premium amount in their wallet. 2. The program operator grants the protocol an allowance for the premium in a supported payment asset. 3. At the period boundary, the protocol pulls the premium amount via the approval. 4. If the order is only partially matched, the protocol pulls a proportionally smaller amount. The program operator retains custody of the funds until the pull settles. Cancelling before the period boundary is as simple as revoking the approval. {% hint style="info" %} If the program operator's wallet balance falls below the premium amount before the period boundary, the pull will fail and coverage will not activate. Monitoring wallet balance and approval state ahead of the boundary is the program operator's responsibility. {% endhint %} ### Matching and issuance At the next period boundary, the matching engine processes orders in priority order: 1. Renewals from existing coverage holders are matched first. 2. Remaining capacity is allocated to new orders. 3. If any queue is oversubscribed, allocations are pro-rated (by prior-period coverage for renewals. By requested amount for new orders). | Outcome | What happens | | ----------------- | ------------------------------------------------------------------------------------------------- | | Fully matched | Premium pulled in full. Cover Token issued for the full requested amount | | Partially matched | Premium pulled proportional to allocated coverage. Cover Token issued for the reduced amount | | Unmatched | No premium pulled. No token issued. The program operator retains the approval for a future period | ### What activation looks like Once the matching engine settles, the program operator: * Holds the Cover Token, with metadata encoding the markets, amounts, period dates, and a reference to the full legal terms document * Receives confirmation of the exact premium charged and any refund applied for partial matches * Is covered from the start of the new period through its end, subject to the cover terms referenced by the token ### Renewal A program operator who wants continuous coverage marks the cover for renewal, which places them in the priority queue at the next boundary. Renewal premiums are repriced at the new period's rates, which may differ from the original coverage as the monitored risk view for each market changes. If the program operator does not renew, the Cover Token expires at the end of the period. ### Visual flow: the commercial side
The commercial-flow diagram shows how cover is enabled and how premiums circulate between stakers, the operator, the vault, and the Network Treasury: 1. **Stakers** deploy capital into the **Firelight Protocol** and receive their staked position plus ongoing vault rewards. 2. The **Program Operator** sends a quote request and the upfront premium to the **Cover Engine + Agent**. 3. The Cover Engine prices the request, matches it against the Firelight Vault's available capacity (which backs cover), and on confirmation issues one **Cover Token** per period to the operator. 4. Premium flows into the reward pipeline. Part compounds back into the Firelight Vault, raising redemption value for stakers. A portion is routed to the **Network Treasury** as protocol fees. 5. Network Treasury fees fund protocol operations, service providers, and Risk Consortium engagement. While the cover period is active, the Cover Token is held by the Program Operator. {% hint style="info" %} **What is Covered?**\ A vault where the Program Operator has enabled coverage is the recipient of any payouts from a valid claim. The Program Operator determines how the payout is dispersed. {% endhint %} ### Where to read next * [Cover Tokens](/for-program-operators/cover-tokens) details the token structure. * [Pricing](/for-program-operators/pricing) explains how the quote is built. * [Claims Process](/for-program-operators/claims-process) covers what happens when a covered incident occurs. # Cover Tokens Every active Firelight coverage position is represented by a **Cover Token**: an on-chain ERC-721 token held in the program operator's wallet. It is not an NFT collectible. It is a non-fungible on-chain record of what a program operator has elected to cover, including the beneficiary address used for payouts. ### One token per coverage position, per period A program operator receives one Cover Token per coverage position for the 30-day period it covers. The token carries the full coverage state on-chain. Its core metadata fields are: | Field | Description | | ----------------------- | ------------------------------------------------------------------------------------------------------------------- | | coverAmount | Total aggregate coverage in the coverage position's denomination | | markets\[] | Per-market breakdown: chain, protocol, market, allocated amount, with an optional pool identifier for DEX positions | | rate | Weighted average premium rate for the coverage position | | premium | Premium settled at matching | | beneficiary | Program Operator designated address that receives any payout for the Cover Token | | periodStart / periodEnd | Activation and expiry timestamps for the 30-day period | | termsURI | Reference to the full legal cover terms, published to IPFS | | status | ACTIVE, EXPIRED, or SETTLED | The `termsURI` field anchors the full cover terms for that period. Cover Tokens sharing identical terms reference the same document. The complete terms are published to IPFS closer to launch. ### Token states A Cover Token moves through a small set of states: | State | Meaning | | ------- | ------------------------------------------------------------------------------------------------------------------------------------- | | ACTIVE | Coverage is live for the current period. The vault with enabled coverage is covered for declared markets up to the allocated amounts. | | EXPIRED | The period has ended without the cover being renewed. No further coverage applies. | | SETTLED | The token's coverage has been fully consumed by validated payouts. | ### When a covered incident occurs Firelight automatically determines coverage by reading active Cover Tokens. When a covered incident occurs, the protocol identifies exposed positions and includes valid coverage in the payout set. Approved payouts are sent directly to the token's beneficiary address. See [Claims Process](/for-program-operators/claims-process). Because coverage is managed directly on-chain, an ACTIVE Cover Token remains in the holder's wallet throughout. Transfer behavior during an open incident is governed by the cover terms to ensure positions remain consistent until resolution. ### Partial and repeated payouts A single incident may consume less than the full coverage amount. The token tracks remaining cover, and the holder remains covered for the unconsumed remainder of declared markets through the rest of the period. If multiple covered incidents occur in the same period, each draws down the token's remaining cover until the period ends or the token is fully consumed (status SETTLED). ### Where to read next * [Claims Process](/for-program-operators/claims-process) covers the auto-inclusion flow from incident detection to settlement. * [On-Chain Components](/protocol-architecture/on-chain-components) describes the Cover Token and Claims Registry contracts. # Pricing Firelight prices coverage from a per-market premium rate that reflects the risk components the protocol monitors in real time. This page explains, at a high level, what drives a premium and what is published on-chain. It avoids formulas. The methodology reference is in [Risk and Pricing Model](/risk-and-pricing-model). ### What drives the premium A market's premium reflects Firelight's live view of that market's risk, built from two independent sides: * **Economic side.** Market-driven risk. The protocol monitors a near-term bad-debt view (how likely a bad-debt incident is over the next 30 days, and how severe it would be) and a structural graph overlay that watches relationships between collateral and the loan tokens it backs. Both contribute to the economic component of the premium. * **Technical side.** Code and infrastructure driven risk: smart contract bugs, oracle and integration fragility, upgrade patterns, and chain-level posture. This is scored separately and forms the technical component of the premium. Across both sides, signals are organized across the same four risk components and updated continuously: | Component | Example signals that move the rate | | ---------- | --------------------------------------------------------------- | | Blockchain | Network incidents, finality and validator health | | Protocol | Audit status, exploit history, oracle and admin-control changes | | Asset | Volatility, liquidity depth, depeg behavior | | Strategy | Leverage, composition, liquidation headroom | On top of the expected cost of covering a market, the premium includes the cost of the capital backing it. Higher monitored risk on either side means a higher rate. A critical signal (such as an active exploit or a lapsed audit) can remove a market from coverage entirely. ### What is published on-chain For each approved market, the Cover Registry publishes, refreshed every 30 days: | Parameter | Description | | --------------------------- | -------------------------------------------------------------------------- | | Base premium rate | The market's premium as a percentage of coverage | | Available limit by protocol | How much coverage capacity remains available for that protocol this period | Within a period the published rate is fixed for program operators. Between periods it can move as the monitored risk view updates. ### From rate to program operator premium A program operator's premium is the coverage-weighted blend of the per-market rates across the markets they select, applied to the coverage amount for the 30-day period and paid through the vault operations. The quote shows the blended rate, the per-market rates that drive it, and the total premium due. {% hint style="info" %} Numbers in any worked example are illustrative. Published rates and available limits vary by market and period, and the detailed pricing methodology is under active calibration. Cover Registry values take precedence. {% endhint %} ### Capacity limits Coverage on a market is available only up to the published available limit for that protocol. If a program operator's requested allocation exceeds the available limit, the matching engine reduces the allocation to what remains and either reallocates within the program operator's declared set (if capacity exists) or returns a partial match with a proportional premium refund. Markets not on the approved list cannot be quoted. ### Where to read next * [Risk Pricing Framework](/core-concepts/risk-pricing-framework) for the high-level model. * [Risk and Pricing Model](/risk-and-pricing-model) for the methodology reference. * [Claims Process](/for-program-operators/claims-process) for how a covered incident becomes a payout. # Claims Process Firelight does not require program operators to file claims. When a covered incident occurs, the protocol identifies every active Cover Token exposed to the affected market and includes it automatically. No portal, no submission, and no action from the operator. ### Auto-detection When an exploit is confirmed, the registry identifies every Cover Token with an active position in the affected market and includes it in the incident. Validation runs against on-chain state, not against anything the operator files, so a covered operator cannot miss a payout by failing to act. The Cover Token is the only artifact in the flow. It carries the evidence that coverage is enabled on the vault and tracks what remains after each payout. A partial payout leaves the rest in force for the period. ### Incident lifecycle A covered incident moves through six phases. Partner service-level targets set the pace, not protocol deadlines. The backstop is the period boundary: an incident unresolved by the end of the following period expires with no payout.
1. **Exploit Confirmed.** Monitoring detects a potential exploit. The curator opens the incident on-chain. The curator here is the same role introduced in [Introduction → Who participates](/introduction): the entity that designs vault strategies also performs incident curation for the protocol. This freezes the exposed Cover Token set and pauses vault deployments. 2. **Exploit Report.** An independent security partner publishes an exploit report on-chain. Assessment cannot begin until it is recorded. Target: 48h. 3. **Assessment.** The protocol calculates a proposed loss schedule through automated check of Cover Tokens with exploited market exposure. The Risk Consortium validates it. Assessors confirm the amounts rather than recomputing them. Approval requires a 3-of-5 quorum. Period expiry is the backstop. Target: 24h protocol report and 72h validation. 4. **Liquidation.** Approval triggers settlement automatically. The First-Loss Buffer absorbs the first tranche. If exhausted, the vault is slashed pro-rata for the remainder, and slashed assets are converted to stablecoins. 5. **Payout.** Proceeds go to each Cover Token's beneficiary address, pro-rata to approved loss. If proceeds fall short, every beneficiary takes the same proportional reduction. 6. **Closed.** Distribution completes and the incident is finalised. Deployments pause when an incident opens, so capital entering afterward does not absorb its loss. Deployments reopen when the slash settles, the incident is canceled, or the next period begins. Withdrawals and cover settlement are unaffected. | Stage | Activity | Owner | | --------------- | ------------------------------------------------------------------------- | ---------------------------- | | Detection | Potential exploit flagged | Monitoring infrastructure | | Confirmation | Incident opened and exposed Cover Tokens frozen | Curator | | Reporting | Exploit report published. Target: 48h | Independent security partner | | Loss assessment | Loss schedule calculated. Target: 24h | Curator | | Validation | Approve or Deny with a 3-of-5 quorum, with written rationale. Target: 72h | Risk Consortium | | Settlement | Buffer draw, pro-rata slash, and liquidation | Liquidation service | | Payout | Pro-rata distribution to beneficiaries | Firelight Network | | Recovery | Recovered assets returned to stakers after settlement | Firelight Network | See [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed) for the validation model and [Claims Liquidation](/protocol-architecture/claims-liquidation) for settlement mechanics. ### Where to read next * [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed) covers the consortium's process. * [Claims Liquidation](/protocol-architecture/claims-liquidation) goes deeper on the liquidation mechanics. # Supported Protocols and Markets Coverage is available only for markets that have been explicitly approved by the Firelight Risk Committee and added to the Cover Registry. This page describes how that list is maintained and what shows up in it at the feature-complete launch. ### How the approved list works A market is a combination of three attributes (with an optional fourth for DEX positions): | Attribute | Description | Example | | --------------- | --------------------------------------- | ----------------------- | | Chain | The blockchain network | An EVM chain or L2 | | Protocol | The DeFi protocol hosting the market | A lending market or DEX | | Market | The specific market within the protocol | A named lending market | | Pool (optional) | For DEX positions, the specific pool | A named liquidity pool | Every market on the approved list has gone through Firelight's risk assessment: the protocol's risk components are monitored, capacity limits are set, and a base premium rate is published. The approved list is published in the on-chain Cover Registry with current available limits and base premium rates, and program operators should treat the registry, not this page, as the operative list. ### Minimum eligibility For a market to be considered at all, the underlying protocol must meet minimum standards: | Requirement | Minimum standard | | -------------------- | ------------------------------------------------------------ | | Security audit | At least one comprehensive audit by a recognized firm | | TVL threshold | A minimum TVL level sustained over a meaningful period | | Operational history | A minimum time live on mainnet without a critical exploit | | Team identification | Publicly identified team members with verifiable credentials | | Governance structure | Documented governance with transparent decision-making | | Bug bounty program | An active bug bounty with a meaningful maximum payout | Markets that do not meet these requirements are not eligible, regardless of demand. Certain conditions (an active incident, a lapsed audit, a sharp TVL decline, or an unverifiable team) trigger automatic exclusion regardless of other factors. ### At the feature-complete launch At launch, the approved list focuses on: * Major EVM lending markets (selected markets on established lending protocols) * Major DEX liquidity positions (selected pools on established DEXs) * A curated set of strategies built on top of these primitives The list starts small and expands over time as additional markets clear risk review and Risk Committee approval. ### Collateral assets for stakers Coverage is backed by staked capital. At the MVP, the single eligible collateral is **stXRP** (the Phase 1 staking token, backed by XRP via FXRP on Flare). Support for additional collateral assets is on the roadmap and would be added through governance in later versions. See [Staking Overview](/for-stakers/staking-overview) for the staker side. ### Payout currencies Approved payout stablecoins are published on-chain and consist of major, audited stablecoins. Each Cover Token records a payout currency. At settlement the liquidation service fills in that currency first and falls back through the supported set if liquidity is insufficient. See [Claims Process](/for-program-operators/claims-process) for the fallback rules. ### How to propose a new market An institution that wants a specific market added can submit a coverage request. The request triggers a preliminary eligibility screen, a full risk assessment if it clears the screen, a pricing-and-limits proposal, and publication to the Cover Registry on approval. Timelines depend on data availability and protocol complexity. ### Where to read next * [How Coverage Works](/for-program-operators/how-coverage-works) for the enablement flow. * [Risk Pricing Framework](/core-concepts/risk-pricing-framework) for how rates are produced. # For Stakers This section is for stakers: anyone staking stXRP into the Firelight protocol to back coverage and earn protocol emissions. {% hint style="info" %} Staking is **permissionless**, anyone can stake FXRP. (Enabling cover, by contrast, is permissioned to institutions in the MVP.) {% endhint %} ### What you'll find here * [Staking Overview](/for-stakers/staking-overview) explains what staking FXRP does and what you receive in return. * [Emission Mechanics](/for-stakers/emission-mechanics) base rate emissions, protocol-related rewards and how Firelight Points fit in. * [Risk and Exposure](/for-stakers/risk-and-exposure) describes what a staker is backing, how slashing works, and how staked capital converts into coverage capacity and leverage. * [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals) walks through activation, the unstaking window, and the exit flow. ### What to know before staking Once coverage is live on mainnet, all staked capital in the vault backs coverage and is slashable. Slashing only occurs if a validated claim exhausts the First-Loss Buffer. Even then it is pro-rata across all positions, and the amount is fixed at the time the slash instruction is generated. In exchange for this exposure, stakers earn protocol-related rewards alongside the underlying stXRP base rate emissions. Rewards come from two sources: * The underlying stXRP base rate emissions * Protocol-related rewards funded by program operators and protocol emissions ### How to participate 1. Obtain stXRP: stake XRP via FXRP on Flare. The same flow Firelight launched with in Phase 1 (see [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals) for the prerequisites). 2. Stake FXRP into the Firelight protocol through the protocol interface. 3. Once the deployment clears screening and becomes active, rewards begin accruing. 4. To exit, initiate an unstake. Your stXRP is redeemed and your FXRP becomes withdrawable at the end of the cover period following the one in which you unstaked. Additional assets beyond stXRP are on the roadmap for future versions. # Staking Overview Staking in Firelight Coverage means contributing FXRP into the Firelight protocol to back coverage and earn a share of protocol emissions. This page covers the basics: what happens at deployment, what a staker holds, and how this relates to the Phase 1 staking product Firelight launched with. ### What you stake At the MVP, the single supported asset is FXRP, the staking token Firelight launched with in Phase 1, backed by XRP via FXRP on Flare. Staking is permissionless. When you stake stXRP to the Firelight protocol, your collateral is utilized to back cover that is actively enabled on existing program vaults, and you accrue a share of protocol emissions plus potential emission boosts. Once coverage is live on mainnet, all capital in the protocol is utilized to back active coverage and is subject to slashing if a validated claim exhausts the First-Loss Buffer. Stakers accept that exposure in exchange for a share of protocol emissions. Slashing behavior and the loss waterfall are covered in [Risk and Exposure](/for-stakers/risk-and-exposure). ### What you receive at deployment A deployment produces an on-chain position in the vault that: * Tracks your proportional claim on the vault's assets * Accrues both base rate emissions and potential claimable coverage-related rewards The vault follows the ERC-4626 standard, so the position's redemption value against the underlying rises as rewards accrue. The supply of your vault shares does not expand as rewards accrue. Instead each share becomes redeemable for more of the underlying, effectively compounding the protocol emissions into the deployed capital. ### Activation timing Deployments activate without waiting for a period boundary. Each deployment moves through compliance screening; once it becomes active, rewards (base rate emissions) begin streaming. There is no period-aligned waiting for new deployments to start earning. ### Where the underlying sits Staked capital reside in the vault. The vault itself is non-custodial at the smart-contract layer. Stakers retain control of their capital cryptographically. ### Relationship to the Phase 1 staking product Firelight Coverage builds directly on the stXRP product Firelight launched with in Phase 1. Existing stXRP holders can stake into the Firelight protocol to begin backing and earning premium income. The core staking mechanics are unchanged. Coverage adds the premium distribution and the corresponding slashing exposure. The Phase 1 documentation is being retired as the coverage protocol goes live; the staking content that remains relevant lives in this section, and the Phase 1 reference terms (FAssets, FXRP, FLR, Launch Vault) are defined in [Glossary](/resources/glossary). #### Launch phase positions auto-convert If you held a position in the Phase 1, that position is **automatically converted to a staked position** in the Firelight protocol when Phase 2 goes live. No action is required from the staker. Your position transitions into a backing position at cutover, and from that point earns the base rate emissions from premiums. The corresponding slashing exposure also begins at the transition, in line with the rest of the vault. ### Where to read next * [Emission Mechanics](/for-stakers/emission-mechanics) covers how premium income is distributed and how Firelight Points work. * [Risk and Exposure](/for-stakers/risk-and-exposure) explains slashing, the loss waterfall, and how capital converts into coverage capacity. * [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals) walks through the operational flow. # Emission Mechanics Stakers earn from two sources: the base rate emissions on stXRP, and protocol-related rewards funded by protocol emissions boosts. This page explains how each accrues and how Firelight Points fit in. | Source | What it is | How it accrues | | ------------------------ | ------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Base rate emissions | The native staking rate on stXRP from coverage premiums | Accrues into the vault, raising the position's redemption value | | Protocol-related rewards | Rewards funded by protocol emission boosts | Protocol emission boosts are distributed outside of the vault to directly to stakers | ### How coverage premiums accrue Settled premiums stream into the vault on a regular cadence rather than as a single period-end distribution, so a deployment made mid-period begins earning shortly after deployment. Premiums are converted into the vault's collateral asset and compound into the redemption value. ### Protocol-related rewards In addition to auto-compounding coverage premiums, stakers can receive emission boosts for participation. Protocol-related rewards are claimable rather than auto-compounded. ### Firelight Points Firelight Points carry over from Phase 1 into the coverage phase. They accrue based on the amount staked and the time held, and run alongside the base rate emissions and other rewards above as a loyalty and engagement measure. They are not a claim on premiums. #### **How points are calculated** Your Firelight Points are determined by three factors: the total amount of stXRP you hold (both in your wallet and deployed in DeFi protocols), the length of time you hold it, and your Boost. Balances are snapshotted hourly on the last block of each hour, and points accrue for every fully completed hour. $$ \text{Firelight Points} = \left( \text{stXRP}*{\text{held}} + \text{stXRP}*{\text{DeFi}} \right) \times \text{Time}\_{\text{held}} \times \text{weightedBoost} $$ **weightedBoost** is determined by the different boosts assigned to holding stXRP and the different boosts assigned to DeFi deployments of stXRP. The calculation runs continuously, rewarding consistent participation in the ecosystem. ### What stakers see in practice 1. Stake FXRP and receive stXRP as a vault position. 2. The position's redemption value rises continuously as base rate emissions accumulate. 3. Firelight Points accrue based on amount and duration staked. 4. To exit, initiate an unstake (redeeming your stXRP and ending emissions accrual), wait for the unstaking window to end at the close of the following cover period, then withdraw the underlying FXRP. ### Where to read next * [Risk and Exposure](/for-stakers/risk-and-exposure) covers the other side of the return profile, plus capacity and leverage. * [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals) covers what accrues during an active position. # Risk and Exposure Staking **FXRP** into the Firelight protocol means backing coverage. This page describes what that involves: what can cause losses, how the loss waterfall protects stakers from smaller incidents, how slashing is applied, and how staked capital converts into coverage capacity through diversified leverage. ### What a staker is backing The vault backs every active Firelight coverage position. If a validated claim is paid and the First-Loss Buffer is exhausted, the remaining loss is met by slashing vault positions. A staker is not backing a single market. The exposure is to the aggregate claim experience of the protocol across all covered markets during the periods their collateral is active. Diversification is managed at the portfolio level through the risk framework and the limits described below. ### The loss waterfall Losses from a validated claim are absorbed in two layers, in order: 1. **First-Loss Buffer.** A protocol-owned stablecoin reserve. This layer absorbs the smallest incidents entirely, without touching staker collateral. 2. **Vault slashing.** Any remaining loss is allocated pro-rata across staker positions in the vault. A staker's position is only reduced if a claim is large enough to exhaust the First-Loss Buffer and reach the vault. Smaller incidents never affect staker balances. ### How slashing is applied When a slash instruction reaches the vault: 1. The contract reads the current vault balance at execution time. 2. The slashed amount is deducted pro-rata across all positions. 3. The slashed collateral is routed to the liquidation service for conversion into payout stablecoins. Pro-rata allocation means every staker takes the same percentage reduction. A position twice the size of another absorbs twice the dollar loss. No position is exempt and no position is singled out. The slash amount is fixed at the moment the instruction is generated, subsequent liquidation slippage does not expose the staker to additional loss (the First-Loss Buffer absorbs any shortfall first). ### Sequential slashing across multiple incidents If multiple incidents occur in the same period and require slashes, they are processed sequentially: a later incident's slash is calculated against the post-prior-slash vault balance, and a concurrency guard prevents overlapping slashes on the same vault. ### What is not a slashing event | Scenario | What it is | | ----------------------------------------------------------- | -------------------------------------------- | | stXRP price drifts on a DEX | Market price deviation, not a protocol slash | | Redemption value declines slightly after a large withdrawal | Normal accounting adjustment, not a slash | | Protocol emission value fluctuates | Market pricing of a separate asset | Only an on-chain slash instruction from a validated claim reduces a staker's underlying balance. ### What happens after a slash * The staker's vault share balance remains the same. * The vault's redemption value decreases to reflect the reduced backing. * Future emission streams continue, rebuilding the redemption value over time. ### How capital becomes coverage capacity A dollar of staked capital backs more than a dollar of coverage, because losses are rare and partial rather than continuous and total. The amount of coverage per dollar of capital is **effective leverage**, bounded by a floor and ceiling, with the protocol operating conservatively at launch while diversification builds. Effective leverage is the product of a nominal ratio and a **Diversification Factor** that rises with portfolio diversification and falls with concentration. A well-diversified portfolio earns a higher Diversification Factor and can be operated at higher effective leverage safely. A concentrated portfolio tightens leverage and reduces capacity. At each period boundary the matching engine computes available capacity from available capital, First-Loss Buffer plus the market value of staked collateral, effective leverage, and the coverage already active. A **Capital Adequacy Ratio (CAR)** floor caps how much the protocol will back relative to capital. The engine will not allocate capacity that would push CAR below its floor. The full methodology is in [Capital Adequacy](/risk-and-pricing-model/capital-adequacy). ### Two-view exposure A staker's exposure aggregates two independent views of the book. The **economic view** combines a near-term bad-debt expectation for every covered market with a structural graph overlay that captures collateral → loan-token relationships. The **technical view** captures the protocol and infrastructure-level risk of the same markets. Both views feed the portfolio expected loss that drives capital adequacy, so a staker is implicitly exposed to whichever side moves first, a market that looks technically clean can still raise the staker's underlying risk if its economic view deteriorates, and vice versa. ### What this means for a staker * **Base rate emissions.** More coverage written per dollar of capital means more rewards flowing to stakers. * **Safety margin.** The CAR floor and the First-Loss Buffer bound how much loss can reach the vault, keeping staker exposure to tail events. A staker is taking on slashing risk from validated claims that exhaust the First-Loss Buffer, normal smart-contract risk from the Firelight contracts, and the underlying stXRP risk (yield, volatility, peg mechanics). In exchange they receive the underlying base rate emissions from premiums plus coverage-related rewards. ### Where to read next * [Capital Adequacy](/risk-and-pricing-model/capital-adequacy) for the full capacity, leverage, and CAR methodology. * [Claims Process](/for-program-operators/claims-process) for the payout side of the waterfall. # Deployments and Withdrawals This page covers the operational mechanics a staker encounters when entering or exiting the Firelight vault: the prerequisites for staking, activation of new deployments, the unstaking window, and the period-level behavior that governs both. ### Prerequisites: getting stXRP Staking into the Firelight protocol uses stXRP, the staking token Firelight launched with in Phase 1. New stakers go through the same three-step prerequisite chain that has applied since launch: 1. **Obtain FXRP.** Wrap XRP into FXRP via Flare's FAssets system. FXRP can also be acquired on supported EVM chains or exchanges and bridged to Flare. See the Flare and FAssets documentation for the deep walk-through. 2. **Obtain FLR.** FLR is the native token of the Flare network and is needed for gas on Flare. A small balance is enough for the staking flow. 3. **Stake FXRP into the Firelight protocol.** Approve and deploy FXRP through the Firelight interface; the protocol issues stXRP representing your position. The stXRP balance is what backs cover. After the cutover to Phase 2, stXRP held in the Phase 1 is **automatically converted** to an active staked position in the protocol. No staker action is required for the migration itself (see [Staking Overview](/for-stakers/staking-overview) for the cutover detail). #### Activation Deployments activate without waiting for a period boundary. Once the deployment transaction confirms: 1. The vault records the position in a single atomic transaction. 2. The deployment moves through compliance screening. 3. Once screening clears and the deployment becomes active, it is added to the protocol's staked balance and rewards begin streaming. A deployment made late in a period earns rewards for the remainder of that period once active. There is no waiting for the next boundary to start earning. Slashing exposure begins at the same moment: once a deployment is active, its capital is part of the backing and takes any pro-rata slash from a validated claim, even in its first period.
The diagram shows a stake entering mid-period (Day 45 of Cover Period 1). It begins earning protocol emissions immediately once active, and assumes slashing exposure at the same moment. There is no waiting for the next period boundary. {% hint style="info" %} Periods are currently **1 day** long, so the unstaking window is currently 1 to 2 days. The day counts highlighted above reflect the **30-day cover period** lengths that take effect when the Feature-Complete Launch is live. {% endhint %} #### What counts toward coverage capacity Although deployments activate immediately for base rate emissions, they count toward coverage capacity at the next period boundary, when the matching engine recomputes capacity for the following period. In practice a mid-period deployments starts earning base rate emissions right away, while its contribution to new coverage allocation shows up in the next period's capacity calculation. This is a consequence of deterministic period settlement: each period settles based on its starting state, so mid-period flows take effect in the next period. #### Steps The deployment flow follows the same pattern Firelight launched with in Phase 1 against the Launch Vault: approve the vault to spend stXRP, call deployment, and receive the vault position. Stakers who used the original flow will find no interface changes for the basic deployments. ### Withdrawals Unstaking is a two-step process: initiate, then withdraw. #### Step 1: Initiate The staker submits an unstake request specifying the amount to unstake. On submission the protocol records the request and the position enters the unstaking window. The corresponding stXRP is redeemed at the time of request a snapshot of its redemption value is taken. Redemption ends emissions accrual immediately and removes the position from the next period boundary's coverage-capacity calculation. {% hint style="info" %} The unstaking window is **one full period after the period in which the unstake is initiated**: the underlying FXRP becomes withdrawable at the end of the period following the unstake. **Currently (1-day periods):** the unstaking window is 1 to 2 days, depending on when in the day the unstake is initiated. **At the feature-complete launch (30-day cover periods):** the same mechanic applies to 30-day cover periods, so the window extends to just over 30 to 60 days. Because staked collateral is actively backing in-force coverage, the window is set so that capital cannot exit ahead of the coverage obligations it backs. {% endhint %} #### Step 2: Withdraw After the unstaking window ends, the staker returns to withdraw the underlying. Withdrawing executes the final transfer from the vault to the staker's address. Withdrawals are not automatic, a staker who initiates an unstake but never returns to withdraw leaves the assets in the vault until they submit the withdrawal transaction. #### Unstaking Window Since the unstaking window ends at a period boundary rather than a fixed number of days after initiation, the total length of the unstaking window depends on when in the period they initiate. With today's 1-day periods, this means an effective lock of 1 to 2 days. The protocol does not add additional waiting on top of the window.
The diagram shows two unstake scenarios (Day 10 and Day 29 of Cover Period 0) that both become withdrawable at the same moment at the end of Cover Period 1. These scenarios show Feature-Complete Cover Period lengths. **Slash exposure during the unstaking window** Redeeming the stXRP ends reward accrual, but it does not end slashing exposure. The window has two phases: **Backing coverage:** Your capital is still backing coverage in Firelight for the remainder of ther period where you initiated the unstaking process. If an exploit incident occurs during this period, the pending withdrawal takes the same pro-rata slash as active positions. **Reconciliation window:** Your capital no longer backs new coverage and is not exposed to incidents that occur in this period. However, if an exploit incident is attributed to a period in which your capital was still backing coverage, the resulting slash still applies to the pending withdrawal. #### Rewards during unstaking window Emissions stop accruing at the moment an unstake is initiated because the stXRP is redeemed at initiation and its redemption value is snapshotted then. A position in the unstaking window earns neither base rate emissions nor a share of protocol emissions. ### Interactions with coverage matching When an unstake is initiated, the redeemed stXRP is excluded from the next period boundary's capacity calculation. This is handled by the protocol. From the staker's perspective the only concern is the unstaking window length. ### Blocklist and rescues Vaults implement a blocklist to comply with regulatory requirements. Blocklisted addresses cannot deploy, withdraw, or transfer. Authorized roles can rescue assets from blocklisted accounts and reassign them to a non-blocklisted address, preserving the position without violating compliance constraints. Most stakers never interact with these mechanics. ### Summary of operational parameters | Parameter | Value at feature-complete launch | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deployment activation | Without waiting for a period boundary | | Reward streaming cadence | Regular (targeting steady daily accrual) | | Unstaking window | One full period after the period of initiation. Currently 1–2 days with 1-day periods. Extends to 30-day cover periods at the feature-complete launch with unstaking window range being 30-60 days | Values are subject to adjustment after launch. ### Where to read next * [Emission Mechanics](/for-stakers/emission-mechanics) covers what accrues during an active position. * [Risk and Exposure](/for-stakers/risk-and-exposure) covers slashing and how deployments feed coverage capacity. # Risk Consortium The Risk Consortium is the independent body that validates covered incidents. Without it, payouts would depend on either automated rules (too rigid for the realities of exploit classification) or a single administrator (too centralized to trust). The consortium sits between those extremes: independent domain experts applying published coverage criteria to on-chain evidence. ### Confirmed members The consortium launches with five confirmed members: * Hypernative * Cyfrin * Credora * GFX Labs * Native ### What you'll find here * [Role of the Consortium](/risk-consortium/role-of-the-consortium) defines the consortium's scope, responsibilities, and limits. * [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed) details the validation and voting procedure under the auto-inclusion model. * [Becoming a Member](/risk-consortium/becoming-a-member) describes eligibility and the terms of participation. ### Why the consortium exists Exploit classification is judgment-heavy: * Was a governance outcome a malicious exploit or a legitimate vote? * Was a liquidation cascade a mechanism failure or market behavior within design parameters? * Did an oracle deviation reflect manipulation or ordinary cross-exchange drift? These are not questions a smart contract can answer on its own. They require technical review of on-chain evidence by people who understand the underlying protocols. ### What the consortium is not The consortium is not a backer or risk-pricing authority, a program operator or fund custodian, a designer of coverage criteria or pricing, or a marketing arm of Firelight. Its authority is limited to applying existing coverage criteria to reported incidents and voting on whether those incidents qualify. It does not set premiums, modify terms, hold collateral, or execute fund transfers. ### How decisions flow Because Firelight uses auto-inclusion, the consortium does not wait for program operators to file claims. Once an incident is detected and reported: 1. An independent security partner delivers an exploit report on-chain. 2. The protocol auto-includes every active, in-scope Cover Token exposed to the incident. 3. Consortium members validate the incident against the published coverage criteria and declare any conflicts. 4. Members vote Approve or Deny. A 3-of-5 quorum is required. 5. If the quorum and approval threshold are met, the decision is signaled on-chain and triggers the payout waterfall. ### Where the consortium appears in the rest of the docs * [Claims Process](/for-program-operators/claims-process) shows the consortium's role from the program operator's perspective. * [On-Chain Components](/protocol-architecture/on-chain-components) documents the contracts the consortium interacts with. # Role of the Consortium A member of the Risk Consortium is an independent technical expert engaged by the Firelight Network to review reported coverage incidents and vote on their validity. This page lays out what that role entails, what members are expected to do, and the explicit limits on their authority. ### Core function A member's core function is to review the factual and technical evidence associated with a reported incident and to submit an on-chain signal on whether the incident meets the pre-defined coverage terms. This is a verification role, not a discretionary one. Members apply existing coverage terms to the evidence in front of them. They do not interpret those terms creatively or extend them to novel scenarios without governance action. ### Mandatory responsibilities Every member is expected to: * **Vote on auto-included incidents.** Review the exploit report for each incident within the agreed service-level window and vote Approve or Deny. * **Submit a written rationale.** Accompany each vote with reasoning and key parameters, including exploit timestamp, affected protocol, impacted assets, total value exploited, and total value covered. * **Declare conflicts.** A member with a direct or indirect interest in the outcome must declare a non-vote and step out of the process for that incident. ### Optional or conditional responsibilities Members may also publish ongoing risk assessments for protocols on or under consideration for the approved list, share urgent findings privately for rapid internal response, and participate in recovery efforts (eligible for a share of the recovery bounty). ### Limits on member authority The role is bounded. A member does not: | Activity | Not within member authority | | --------------------------------------------------------- | ----------------------------------------------------------- | | Design or amend coverage terms | Reserved for the Risk Committee | | Set premiums or economic terms | Reserved for the Risk Committee and the pricing process | | Hold or manage capital | Handled by the Network and custody layers | | Authorize fund transfers | Executed by smart contracts based on on-chain vote outcomes | | Assume underwriting risk | Borne by stakers | | Act as an underwriter, claims administrator, or fiduciary | None of these roles apply | Consortium outputs are non-custodial verification signals. They support the protocol's automated execution of pre-defined rules. They do not replace those rules. ### Independence and conflicts The consortium operates at arm's length from the entities that build and operate the protocol. Members are expected to be independent of Firelight's core teams and commercial partners, disclose any relationships that could create a conflict, and abstain from voting on any incident where a conflict exists. ### What a member produces For each incident, a member produces a vote (Approve, Deny, or a declared non-vote), a written rationale, and an on-chain signal that contributes to the quorum calculation. The aggregation of these signals drives the protocol's automated response: if the quorum and approval threshold are met, the payout waterfall is triggered. If the incident is denied, no payout occurs and active Cover Tokens remain in force for the rest of the period. ### Where to read next * [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed) walks through the validation procedure. * [Becoming a Member](/risk-consortium/becoming-a-member) covers eligibility and participation. # How Claims Are Assessed This page walks through how the Risk Consortium assesses a covered incident. Because Firelight uses auto-inclusion, there is no program operator-submitted claim to process. The consortium validates the incident itself, and the protocol applies the outcome to every Cover Token already exposed to it. ### Position in the overall flow The consortium owns the validation and vote stages of the incident lifecycle. The other stages, detection, confirmation, reporting, settlement, are owned by monitoring infrastructure, the independent security partner, and the liquidation service. | Stage | Activity | | ---------- | --------------------------------------------- | | Validation | Scope review and conflict declarations | | Vote | Binding Approve/Deny determination | | Recovery | Recovery-bounty participation (if applicable) | ### Validation On receipt of an exploit report from the independent security partner, each member: 1. Reads the full report. 2. Confirms the incident occurred during an active coverage period for at least one Cover Token. 3. Validates that the affected protocol and market are on the schedule of covered items. 4. Classifies the incident against the categories in [Coverage Types](/core-concepts/coverage-types). 5. Declares any conflicts. Validation does not involve re-running the security partner's analysis from scratch. The consortium's job is to apply coverage terms, not to duplicate forensic work. ### The vote Following validation, the consortium votes. A vote has three elements: * **A binary decision** (Approve or Deny) on whether the incident qualifies as a covered claim. * **A written rationale** recording the member's reasoning and the key parameters: exploit timestamp, affected protocol, impacted assets, total value exploited, and total value covered. * **A quorum check** against the consortium's configured threshold. Members who declared a conflict submit a non-vote, which does not count for or against the threshold. #### Quorum and threshold Members vote Approve or Deny. A decision requires a **3-of-5 quorum**. The vote runs against a short service-level window to support fast payout while leaving room for diligence. If quorum is not met within the window, the vote is briefly extended. If still not met, no binding decision is produced in that window. The hard backstop is the period boundary: an incident left unresolved by the end of the following period expires with no payout. ### Conflicts and non-votes A conflict exists when a member has a direct or indirect interest in the outcome, for example, being an employee, advisor, or investor in the exploited protocol, or having produced an assessment that materially influenced the coverage decision being reviewed. The member declares a non-vote, which is recorded on-chain for transparency, and does not participate in that incident's vote. ### What counts as a qualifying incident Members apply the coverage categories and boundary rules in [Coverage Types](/core-concepts/coverage-types). The recurring test is whether a mechanism malfunctioned (qualifying) or behaved as designed (not qualifying): a flash-loan governance exploit qualifies, while legitimate vote accumulation does not. An oracle manipulation qualifies, while normal cross-exchange arbitrage does not. A depeg from a broken redemption mechanism qualifies, while redemption gates working as designed do not. ### Post-vote flow Once the vote closes: 1. The result is published on-chain. 2. If approved, the protocol generates a slash instruction and the incident enters the payout waterfall (see [Claims Process](/for-program-operators/claims-process)). 3. Every auto-included Cover Token exposed to the incident is settled according to the payout calculation. 4. If denied, no payout occurs and active Cover Tokens remain in force for the remainder of their periods. ### Recovery participation Assets recovered after payout (through white-hat negotiation or law-enforcement cooperation) flow back through the waterfall in reverse order of absorption, with a recovery bounty paid to members who actively contributed to the recovery. ### Where to read next * [Role of the Consortium](/risk-consortium/role-of-the-consortium) for the scope and responsibilities that frame this procedure. * [Claims Process](/for-program-operators/claims-process) for the program operator-side view. # Becoming a Member The Risk Consortium is made up of independent technical experts. The MVP launches with five confirmed members (Hypernative, Cyfrin, Credora, GFX Labs, and Native). This page covers who the consortium looks for and the terms of participation. It does not publish compensation specifics. ### Who the consortium looks for The consortium draws from organizations with deep technical expertise in DeFi security and risk. Typical backgrounds include: | Background | What they bring | | --------------------------------------- | -------------------------------------------------------------------------------- | | DeFi risk managers | Protocol-level risk analysis, parameter setting, credit and liquidity assessment | | Security auditors | Smart contract review, exploit pattern recognition, remediation experience | | On-chain forensics specialists | Transaction tracing, attacker identification, evidence assembly | | Monitoring and infrastructure providers | Real-time detection, oracle and bridge expertise | No single member needs to cover all of these. The consortium is designed to aggregate complementary expertise across its members. ### Independence requirement Independence is the gating criterion. Candidates must operate at arm's length from Firelight's commercial teams and from the protocols they assess. That includes no direct employment relationship with Firelight entities, disclosure of advisory roles or investments in covered protocols, and a commitment to declare conflicts and abstain when they arise. Candidates whose independence cannot be maintained are not eligible, regardless of technical strength. ### Selection process The Network engages members through a structured process: introduction or nomination, a capability review against the expertise the consortium wants to cover, an independence check, and a participation agreement on approval. The consortium starts at its confirmed size of five and may expand as coverage volume and protocol complexity grow. ### Terms of participation A participation agreement covers scope of duties, the mandatory voting responsibilities and optional activities described in [Role of the Consortium](/risk-consortium/role-of-the-consortium), response-time commitments, the conflicts policy, confidentiality around non-public exploit information, term and termination, and the basis for compensation. ### What the consortium expects Effective participation requires availability (incidents arrive on the protocol's schedule, not the member's), technical rigor (members are the last line of defense before payout), discretion (exploit information can be time-sensitive), and professional conduct (votes and rationales are on the record). ### Exiting the consortium Members can leave by giving notice under their participation agreement. The Network can also remove members who repeatedly miss response windows, develop unresolvable conflicts, or breach the confidentiality or conflicts policies. ### Where to read next * [Role of the Consortium](/risk-consortium/role-of-the-consortium) for the detailed scope of the role. * [How Claims Are Assessed](/risk-consortium/how-claims-are-assessed) for the procedure members follow on each incident. # Risk and Pricing Model This section is the reference material for Firelight's underwriting methodology. It complements the conceptual material in [Core Concepts](/core-concepts) with more detail on how Firelight monitors risk components, how that monitoring drives pricing, and how the protocol manages portfolio-level capital adequacy. The methodology is built from three ingredients: 1. **What is being covered.** A vault's coverage is decomposed into the strategies that sit inside it. Each one carries a covered exposure amount and a defined risk treatment (see [Economic Model](/risk-and-pricing-model/economic-model) for how this decomposition feeds pricing). 2. **The economic view.** Market-driven risk, monitored in real time and split into a near-term bad-debt view and a structural graph overlay. 3. **The technical view.** Code - and infrastructure-level risk, scored separately and translated into its own portfolio-level expected-loss view. The economic and technical views are kept independent so that markets that look healthy on one side but fragile on the other are still priced correctly. A **composite risk score** blends the two for display and ranking, but pricing uses the underlying split. The framing throughout is deliberately high-level: Firelight prices coverage by monitoring a set of risk components in real time, not by publishing fixed formulas. Specific weights, severity assumptions, and limits are under active calibration, and published values in the Cover Registry take precedence over the descriptions here. ### What you'll find here * [Technical Scoring](/risk-and-pricing-model/technical-scoring) covers the code- and infrastructure-level signals Firelight monitors and how they feed the technical view of a market. * [Economic Model](/risk-and-pricing-model/economic-model) covers the two-component economic view, bad-debt risk plus the structural graph overlay, and the strategy-row decomposition that connects coverage to monitored risk. * [Capital Adequacy](/risk-and-pricing-model/capital-adequacy) describes the leverage framework, the Diversification Factor, and the CAR floor that keeps the protocol solvent under stress. ### How this section relates to the rest | Where referenced | What it's used for | | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | [Risk Pricing Framework](/core-concepts/risk-pricing-framework) | High-level introduction to the two views and the monitored components | | [Pricing](/for-program-operators/pricing) | How monitored risk translates to a program operator quote | | [Risk and Exposure](/for-stakers/risk-and-exposure) | How monitored risk and diversification bound coverage capacity | | [Supported Protocols and Markets](/for-program-operators/supported-protocols-and-markets) | How monitored risk gates eligibility | ### Audience These pages are for readers who want more depth on the methodology: institutional program operators evaluating Firelight's underwriting discipline, capital providers assessing the portfolio risk profile, and partners who need to understand the model well enough to build on it. # Technical Scoring The technical side of Firelight's risk view measures the code- and infrastructure-level risk of each market. This page describes, at a high level, the signals Firelight monitors and how they are kept current. It is a reference companion to the [Risk Pricing Framework](/core-concepts/risk-pricing-framework). ### What technical monitoring covers Technical monitoring focuses on objective, verifiable properties of the underlying code and infrastructure: * Security review history (audit recency, scope, and firm quality) * Known vulnerabilities and exploit history * Code quality and complexity * Infrastructure robustness and uptime * Admin controls, upgradeability, and key management * Operational maturity (time live on mainnet without critical incident) It does not cover market dynamics, governance behavior, or liquidity, those are economic signals (see [Economic Model](/risk-and-pricing-model/economic-model)). ### Signals by component The protocol monitors representative technical signals at each risk component: | Component | Example technical signals | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Blockchain | Validator/node decentralization, finality, client and consensus audits, incident history | | Protocol | Audit count and recency, audit-firm quality, exploit history, bug bounty, upgradeability and admin keys, oracle dependencies, code complexity | | Asset | Token-contract audits, token-mechanics complexity, issuer integrity for wrapped assets, historical incidents | | Strategy | Strategy-contract audits, composability surface, liquidation-logic clarity, upgrade governance | ### How signals are kept current Signals are sourced continuously from a mix of on-chain data (contract code, deployment history, admin-key structures, upgrade incidents, oracle dependencies), public audit reports, bug-bounty program details, and incident databases. Data freshness matters: stale inputs are refreshed before they inform pricing, or flagged so the protocol can take a conservative stance. This continuous refresh is what makes the technical view a live signal rather than a one-time score. As a protocol's technical posture changes, a new audit lands, an exploit is disclosed, an admin key is rotated, the monitored view updates and feeds the next period's published rate. ### Technical signals can gate eligibility directly Some technical findings remove a market from coverage regardless of everything else: * No audit covering the current codebase. * An active exploit or critical vulnerability disclosed. * An admin-key structure without a meaningful threshold or timelock (absent compensating controls). * Code never audited by a recognized firm. These rules prevent a protocol with obvious technical issues from being backed even when other factors look attractive. ### How the technical view feeds pricing The monitored technical signals roll up into a per-market technical risk view that the protocol uses two ways: * **Per-market pricing.** A higher monitored technical risk raises the technical contribution to that market's premium, independently of the economic view. * **Portfolio technical expected loss.** The technical view across all covered markets aggregates into a portfolio-level technical expected loss, which feeds capital adequacy alongside the economic expected loss (see [Capital Adequacy](/risk-and-pricing-model/capital-adequacy)). The technical view runs as a separate track from the economic view. For blended rows it adds to the economic contribution, and for the rare technical\_only row it is the only driver. The two views also blend into a **composite risk score** for display and ranking, which sits alongside, not on top of, the underlying split that pricing actually uses. ### Where to read next * [Economic Model](/risk-and-pricing-model/economic-model) for the market- and governance-level signals. * [Risk Pricing Framework](/core-concepts/risk-pricing-framework) for how monitored risk becomes a price. # Economic Model The economic side of Firelight's risk view captures market- and governance-based risk for each market. It is built from two complementary components, a near-term bad-debt view and a structural graph overlay, and it drives the economic half of every premium. This page describes both components at a high level. It avoids fixed formulas. Specific assumptions are under calibration. ### How coverage maps to economic risk A vault is not priced as a single block. Firelight decomposes a vault's coverage into **strategy rows**, internal pricing units that connect a named strategy to a covered exposure amount, the market that drives its economic risk, and the protocol or chain that drives its technical risk. Each row also carries a **risk mode**: | Risk mode | Treatment | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `blended` | The row is priced from both the economic and technical views. | | `economic_only` | The row is priced from the economic view only, used where market-driven risk is the dominant exposure. | | `technical_only` | The row is priced from the technical view only, used for raw-holdings sleeves where the primary exposure is the token contract or chain. | Strategy rows and risk modes are internal pricing concepts. Program operators see their enabled coverage at the market level. Decomposing into rows is what lets one vault contain a mix of strategy shapes and still be priced coherently. ### What economic monitoring covers Economic monitoring focuses on dynamics that change with market conditions and participant behavior, rather than on properties of the code itself: * Governance attack surface and decentralization * Price volatility of assets and collateral * Liquidity depth and redemption capacity * Concentration of holders, liquidity, or governance power * Historical market behavior under stress These signals feed both components below. ### Component 1: the near-term bad-debt view The bad-debt view answers two market-level questions for each row's risk market: * If the strategy has lending exposure, how likely is a bad-debt incident over the next 30 days? * If that incident occurs, what fraction of covered exposure might be lost? Together with the row's coverage amount these produce a per-row expected loss from bad-debt risk. The probability and severity are updated continuously from on-chain market state and external feeds, so the next period's published rate reflects the latest conditions rather than a stale snapshot. ### Component 2: the structural graph overlay The graph overlay sits on top of the bad-debt view and captures structural economic risk that the near-term model may not yet see. It is scoped to relationships between collateral assets and the loan tokens those collateral assets back. Where the overlay applies, it produces an additional expected loss for the row, independent of, and additive to, the bad-debt view. The overlay uses two named modules: | Module | What it asks | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Liquidity entrapment** | Have borrowers consumed so much of a loan token's available liquidity that lenders may be effectively trapped, even before a bad-debt incident is realized? | | **Collateral contagion** | Can fragile collateral (for example, collateral with recognized structural backing dependencies) drain liquidity from the loan tokens above it, transmitting stress upward? | The overlay is deliberately narrow today: it scores supported collateral → loan-token paths and produces module-level probabilities and severities that combine into the row's graph-overlay expected loss. New paths and modules are added under Risk Committee review. ### Signals by layer Both components draw from signals organised across the same four layers used throughout the framework: | Layer | Example economic signals | | ---------- | --------------------------------------------------------------------------------------------------------------------------- | | Blockchain | Economic security (stake/market cap securing consensus), censorship resistance, validator concentration | | Protocol | Governance-token concentration, voting participation, delegation diversity, parameter-change velocity, treasury composition | | Asset | Trading volume, realized volatility, liquidity depth, depeg history, holder concentration | | Strategy | Strategy leverage, position concentration, liquidation headroom, correlated exposure | The Cover Registry refreshes on the 30-day cadence, so within a period a program operator's premium is fixed, while between periods the published rate moves as the monitored views change. ### From monitored risk to premium Rather than publishing a pricing formula, the protocol frames pricing as follows: * Higher monitored risk on a market, whether driven by the bad-debt view, the graph overlay, or both, implies a higher expected cost of covering it, and therefore a higher premium. * The premium also reflects the cost of the capital backing the coverage, lower operating leverage requires a higher return per dollar of coverage. * A market whose monitored risk crosses the exclusion line, or where a critical signal fires, is removed from coverage rather than priced. ### How economic and technical views combine Each row carries an economic expected-loss view and, when in `blended` mode, a technical expected-loss view. Both feed the portfolio expected loss that drives capital adequacy (see [Capital Adequacy](/risk-and-pricing-model/capital-adequacy)). A **composite risk score** blends the two views for display and ranking. Pricing itself uses the underlying split rather than the composite. {% hint style="info" %} Severity assumptions, the mapping from monitored risk to rate, the specific collateral → loan-token paths supported by the graph overlay, and the weights used in the composite view are actively calibrated and are not published as fixed figures. Cover Registry values take precedence. {% endhint %} ### Where to read next * [Technical Scoring](/risk-and-pricing-model/technical-scoring) for the code- and infrastructure-level view. * [Capital Adequacy](/risk-and-pricing-model/capital-adequacy) for how the economic and technical views feed portfolio-level capital adequacy. # Capital Adequacy Capital adequacy is the portfolio-level discipline that keeps Firelight solvent across all the coverage it writes. This page describes the full framework: available capital, effective leverage, the Solvency Capital Requirement, and the Capital Adequacy Ratio that ties them together. ### The capital adequacy equation The central metric is the Capital Adequacy Ratio: `CAR = Available Capital ÷ Solvency Capital Requirement` | Term | Definition | | ---------------------------- | ---------------------------------------------------------------- | | Available Capital | First-loss buffer (in USD) + market value of staked assets | | Solvency Capital Requirement | The capital the protocol must hold against its in-force coverage | A higher CAR means more capital backing each dollar of coverage. Firelight targets CAR between 1.5 and 2.0 in steady state, and between 1.75 and 2.0 at the feature-complete launch. The Solvency Capital Requirement reflects two things: a coverage-over-leverage component (driven by how much coverage is in force and the protocol's effective leverage) and a portfolio expected-loss component drawn from the live economic and technical views of every covered market. The portfolio-EL term is what makes capital adequacy responsive to the actual monitored risk of the book, not just its size. ### CAR bands and actions Every portfolio state falls into one of five bands: | CAR level | Status | Action | | ------------ | -------- | ----------------------------------------------------------- | | 2.0 or above | Strong | Normal operations. Capacity available for growth | | 1.5 to 1.99 | Adequate | Normal operations. Maintain monitoring | | 1.2 to 1.49 | Watch | Enhanced monitoring. Restrict new coverage | | 1.0 to 1.19 | Warning | Suspend new coverage except renewals. | | Below 1.0 | Critical | Reduce renewal coverage. Implement capital restoration plan | The matching engine enforces these bands on-chain: capacity that would push CAR below the 1.2 floor cannot be allocated. Manual intervention is possible for edge cases but the baseline protection is automatic. ### Effective leverage framework Effective leverage is the bridge between available capital and coverage capacity. It is bounded by explicit floor and ceiling values, with a target range in between: | Parameter | Value | | ---------------------- | ------------ | | Minimum leverage | 1.5x | | Maximum leverage | 5.0x | | Target operating range | 2.5x to 4.0x | | Launch operating range | 2.0x to 2.5x | Effective leverage moves within these bounds based on portfolio diversification. `Effective Leverage = Nominal Leverage × Diversification Factor` Where Nominal Leverage is the unadjusted ratio of total coverage to available collateral, and the Diversification Factor adjusts for portfolio concentration. ### Diversification Factor in depth The Diversification Factor (DF) sits between 0 and 1. Higher values indicate greater diversification and allow higher effective leverage. DF is calculated from weighted concentration scores across the portfolio's layers. Concentration is measured across four dimensions: | Dimension | Metric | Effect on DF | | -------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Protocol | Herfindahl-Hirschman Index (HHI) of protocol exposure | Lowers DF when concentrated in a small number of protocols | | Asset | HHI of underlying asset exposure | Lowers DF when coverage concentrates in one asset class | | Exposure group | Maximum single exposure group as % of portfolio | Penalizes concentration in correlated clusters (for example, shared oracle dependencies) | | Strategy | HHI of strategy types | Lowers DF when coverage concentrates in a single strategy pattern | #### HHI concentration bands | HHI range | Concentration level | Score contribution | | -------------- | ------------------- | ------------------ | | 0 to 1,500 | Low (diversified) | 0.0 to 0.2 | | 1,500 to 2,500 | Moderate | 0.2 to 0.5 | | 2,500 to 4,000 | High | 0.5 to 0.8 | | Above 4,000 | Very high | 0.8 to 1.0 | ### Realized DF in practice Practical Diversification Factors typically fall between 0.5 and 0.7, producing effective operating leverage of 2.0x to 3.5x for a well-managed portfolio. Pushing DF higher than 0.7 requires a genuinely diverse portfolio across protocols, assets, and strategies, which is hard to achieve given the concentrated nature of DeFi liquidity.. ### Stress testing Because part of available capital is denominated in volatile assets, price drawdowns can push CAR lower without any claim activity. The protocol continuously stress-tests CAR against collateral drawdown scenarios: | Drawdown scenario | Post-drawdown CAR behavior | | ----------------- | --------------------------------------------- | | 0 to 15% | CAR remains in Adequate band | | 15 to 30% | CAR drifts toward the Watch band | | 30 to 40% | CAR enters Watch, approaches Warning | | 40 to 55% | CAR enters Warning. New coverage paused | | 55%+ | CAR enters Critical. Renewals also restricted | These bands assume a specific starting leverage and buffer size. As portfolio diversification improves, CAR becomes more resilient to the same drawdown percentage. ### The self-correcting mechanism CAR, leverage, and diversification interact in a self-correcting loop: * Improving diversification raises DF, raises effective leverage, lowers the Solvency Capital Requirement, and improves CAR. * Rising concentration lowers DF, tightens effective leverage, raises the Solvency Capital Requirement, and deteriorates CAR. This means the protocol naturally slows down when it is carrying too much concentrated risk, and accelerates when the portfolio is well balanced. ### Dynamic incentives during drawdowns During periods of collateral drawdown, the protocol can temporarily increase base rate emissions to attract incremental capital. This supports capital restoration without impairing existing coverage obligations. The mechanism is a demand-side response to improve CAR rather than a forced reduction of coverage. ### Why Firelight operates conservatively at launch At the feature-complete launch, Firelight will: * Operate with a modest portfolio (relatively concentrated by HHI standards). * Carry a conservative CAR target of 1.75 to 2.0. * Operate well within the 2.0x to 2.5x leverage band. This produces significant capital headroom and means that even severe collateral drawdowns (50% or more) would not immediately threaten in-force coverage obligations. As diversification improves over time, the protocol can move toward its target operating range. ### Where to read next * [Risk and Exposure](/for-stakers/risk-and-exposure) explains how these mechanics affect stakers. * [Pricing](/for-program-operators/pricing) covers how leverage and capital cost feed into premium. # Protocol Architecture This section documents the protocol's components: the on-chain contracts, the off-chain services, and the liquidation pipeline that executes payouts. ### What you'll find here * [On-Chain Components](/protocol-architecture/on-chain-components) covers the smart contracts stakers, program operators, and the Risk Consortium interact with directly. * [Off-Chain Components](/protocol-architecture/off-chain-components) covers the services that monitor risk, match orders, and drive liquidation execution. * [Claims Liquidation](/protocol-architecture/claims-liquidation) walks through the payout waterfall, liquidation sizing, and post-payout recovery. {% hint style="info" %} A deeper technical treatment of the vault contract surface is maintained separately and will be added once finalized. The MVP-relevant vault model is described in [Core Concepts → Vault Architecture](/core-concepts/vault-architecture). {% endhint %} ### How the pieces fit together Firelight separates responsibilities between contracts and supporting services: * **Contracts** handle things that must be transparent, immutable, or atomic: capacity publication, coverage issuance, the on-chain incident record, vote tallying, slashing instructions, and fund movements. * **Supporting services** handle things that depend on large data inputs or rapidly changing conditions: real-time risk monitoring, premium pricing, order matching at period boundaries, execution sizing for liquidation, and custody-policy enforcement. This separation is designed so that anyone reading on-chain state can verify outcomes (coverage active, incidents validated, payouts executed) even though some supporting computations happen elsewhere. Supporting services publish their outputs on-chain where they are material (for example, the Cover Registry's capacity and rates). ### Trust assumptions | Component | Trust assumption | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Smart contracts | Audited and immutable within version bounds | | Cover Registry parameters | Produced off-chain, written on-chain. Trust in the off-chain monitoring/pricing services and the authorities that can update the registry | | Matching engine | Runs off-chain. Output is visible on-chain (which orders matched at what amounts and premium) | | Liquidation service | Runs off-chain with on-chain settlement. Slashed collateral routes into a permissioned execution pipeline | | Risk Consortium | Independent of the Network and commercial counterparties. Conflicts declared on-chain. 3-of-5 quorum enforced | | Firelight Network | Holds treasury and engages service providers. Does not direct consortium votes or end-user payouts | Where on-chain verification is practical, the protocol uses it. Where it is not (for example, complex risk monitoring), off-chain outputs are signed and written to the relevant contracts. # On-Chain Components Firelight's on-chain surface is the set of smart contracts that hold collateral, issue coverage, record incidents, and execute payouts. This page summarizes each component, what it stores, and who interacts with it. ### Component summary | Component | Role | Primary actors | | ----------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Cover Registry | Publishes per-market base premium rate and available limits | Pricing service (write). Program operators and wallets (read) | | Cover Agent | Quotes and issues coverage tokens | Program operators | | Firelight Vault | Holds staked stXRP, tracks positions, executes slashing | Stakers | | First-Loss Buffer | Stablecoin reserve that absorbs the first tranche of validated losses | Network (top-up), Claims Registry (draw-down) | | Cover Token | ERC-7621 token representing an active coverage position | Program operators | | Claims Registry | On-chain record of incidents, auto-included coverage, consortium votes, and slash instructions | Risk Consortium, protocol | | Fee Distributor | Distributes premiums and vault emission boosts into two flows that auto-compound to stXRP | Matching pipeline (input). protocol and reward emissions (output) | ### Cover Registry The source of truth for market-level coverage parameters. **Stored state:** approved markets (chain, protocol, market, optional pool), base premium rate per market, and the available limit per protocol. **Updates:** refreshed every 30 days at period boundaries from the off-chain pricing service under access control. **Reads:** any program operator or integrating system can read current coverage parameters. ### Cover Agent The entry point for enabling cover on a vault. 1. An onboarded program operator requests a quote for specified markets and amounts. 2. Cover Agent queries the Cover Registry and matching engine for available limits. 3. A quote is returned with per-market rates, a blended rate, premium amount, and validity. 4. On confirmation and period-boundary matching, Cover Agent pulls premium via the program operator's approval. 5. Cover Agent issues a Cover Token to the program operator with the coverage metadata. ### Firelight Protocol Holds staked stXRP and tracks staker positions under the ERC-4626 standard. Core functions cover deployments, withdrawal requests, post-cooldown claims, state queries, and blocklist/pause controls for compliance. The vault exposes slashing hooks triggered by the Claims Registry on a validated claim. All capital in the protocol is utilized in coverage. ### First-Loss Buffer A protocol-owned stablecoin reserve that sits between claims and staker collateral and absorbs the earliest tranche of any validated loss. It is funded by Network top-ups (and, in some configurations, a portion of premium flow), and replenished by recovered assets in reverse waterfall order. Draws are triggered only by the Claims Registry on a validated claim. ### Cover Token An ERC-721 token representing an active coverage position, not an NFT collectible. Full metadata structure is in [Cover Tokens](/for-program-operators/cover-tokens). The token remains in the program operator's wallet. There is no escrow or receipt-token step. ### Claims Registry The Claims Registry replaces the older submit-and-escrow claims flow. It is the on-chain record for the auto-inclusion model: * **Incident record:** when an incident is confirmed and reported, it is recorded here. * **Auto-inclusion:** the protocol identifies active Cover Tokens exposed to the incident and records the included set, program operators do not submit anything. * **Vote aggregation:** the registry exposes a vote interface for Risk Consortium members. Votes and non-votes are tallied on-chain and the 3-of-5 quorum is enforced. * **Slash instruction:** on approval, the registry generates slash instructions specifying the payout. The waterfall is debited sequentially. First-Loss Buffer, then the vault, with a concurrency guard preventing overlapping slashes. * **Settlement:** proceeds are released per the calculation logic in [Claims Process](/for-program-operators/claims-process). Cover Tokens are marked SETTLED when fully consumed. ### Fee Distributor Premium and vault emission boosts flow into the Fee Distributor, which auto-compounds them into the vault. Distribution proceeds on a regular streaming cadence rather than a single period-end distribution. ### Where to read next * [Off-Chain Components](/protocol-architecture/off-chain-components) for the services that feed the on-chain surface. * [Claims Liquidation](/protocol-architecture/claims-liquidation) for what happens after a validated slash. # Off-Chain Components Not everything Firelight does can happen on-chain. Real-time risk monitoring, premium pricing, order matching, and liquidation execution all require data inputs, computation, or external venues that smart contracts cannot access directly. This page covers the off-chain services and how they interface with the on-chain contracts. ### Service summary
ServiceRoleOutput
Risk Monitoring ServiceContinuously monitor risk components for each approved marketA live risk view per market
Pricing ServiceTranslate the monitored risk view into base premium rates and available limitsParameters written to the Cover Registry
Order Matching EngineAllocate coverage capacity at period boundariesMatched orders, premium pulls, Cover Token issuance
Payout Calculation ServiceCompute payouts for validated incidentsSlash instructions
Liquidation Execution ServiceConvert slashed collateral into payout stablecoinsPayout stablecoins distributed to Program Operators
Monitoring and AlertingDetect exploit incidents and protocol stressAlerts, watchlist updates, exploit reports
### Risk Monitoring Service The Risk Monitoring Service implements the continuous monitoring described in [Risk Pricing Framework](/core-concepts/risk-pricing-framework), [Technical Scoring](/risk-and-pricing-model/technical-scoring), and [Economic Model](/risk-and-pricing-model/economic-model). It ingests on-chain data, public audit reports, incident data, and market data. It maintains a live risk view per market and flags markets approaching exclusion thresholds for Risk Committee review. Its outputs feed the Pricing Service and are retained for transparency and calibration. ### Pricing Service The Pricing Service converts the monitored risk view into the on-chain parameters published to the Cover Registry: the base premium rate and the available limit per protocol. It operates under access control, updates to the Cover Registry require signatures from authorized roles and are subject to governance review. Because the underlying risk view is monitored continuously, each period's published rate reflects the latest conditions rather than a stale snapshot. ### Order Matching Engine The Order Matching Engine runs at each period boundary and implements the two-queue priority system described in [Periods and Coverage Cycles](/core-concepts/periods-and-coverage-cycles): 1. Calculate available capacity (First-Loss Buffer + staked collateral value × effective leverage, minus active coverage, minus renewal commitments, plus unstake releases). 2. Process the renewal queue first. Pro-rate if demand exceeds capacity. 3. Process the new-order queue with remaining capacity. Pro-rate if demand exceeds capacity. 4. Pull premiums from prefunded wallets via approvals (partial matches pull proportionally). 5. Route settled premiums to the Fee Distributor. 6. Issue Cover Tokens for matched orders. 7. Refund unmatched premiums. The engine will not allocate capacity that would drop the Capital Adequacy Ratio below its floor. ### Payout Calculation Service When the Risk Consortium validates an incident, this service produces the slash instruction the Claims Registry executes: it determines available payout capacity (First-Loss Buffer plus the market value of staked assets, measured at settlement), computes per-enabled coverage payouts (full if within capacity, pro-rata otherwise) across the auto-included set, and accounts for concurrency guards if another slash is in flight on the same vault. ### Liquidation Execution Service Once collateral is slashed, this service converts it into the payout stablecoins preferred by each Program Operator, using execution strategy scaled to claim size, exchange execution for smaller incidents, OTC and syndicated unwinds for larger ones. It uses regulated venues and counterparties and tracks the slashed collateral value and the realized liquidation proceeds separately. ### Monitoring and Alerting Continuous monitoring watches for incidents that could result in claims or threaten solvency. | Alert | Trigger | | ----------------------- | -------------------------------------------------- | | Critical security alert | Active exploit or critical vulnerability disclosed | | TVL decline | Sharp drop over a short window | | Governance change | Material parameter change or admin-key rotation | | Audit finding | New critical or high-severity finding | | Oracle deviation | Price deviation beyond reference thresholds | Markets showing concerning indicators are placed on a watchlist: new-coverage capacity freezes, monitoring frequency increases, and risk review is triggered if the status persists. ### Where to read next * [On-Chain Components](/protocol-architecture/on-chain-components) for the contracts these services feed into. * [Claims Liquidation](/protocol-architecture/claims-liquidation) for the full payout pipeline. # Claims Liquidation Once an assessment is approved, settlement runs automatically. The protocol draws the buffer, slashes the vault for any remainder, converts slashed collateral to stablecoins, and distributes to beneficiaries. This page covers settlement order, payout capacity, execution, shortfalls, and recovery. ### Settlement order Incidents settle FIFO by confirmation time. The first-confirmed incident pays first. The next pays from whatever remains. Each incident triggers exactly one slash, one liquidation, and one distribution. There is no repeat slashing for the same incident. ### Settlement cooldown Before any distribution executes, there is a **12-hour cooldown** after the distribution's Merkle root is published on-chain. The cooldown provides a final validation window: a distribution can be cancelled during this period if an error or a key compromise is detected. Once the cooldown elapses, settlement proceeds automatically. ### Payout capacity A single value bounds every payout: `totalPayoutCapacity = first-Loss buffer + market value of staked assets` Capacity is measured at settlement. No per-market cap applies at payout. Market caps govern cover sales only. If approved loss is within capacity, the incident pays in full. If it exceeds capacity, beneficiaries share what is available pro-rata. After each incident, capacity is reduced by the amount paid. ### The waterfall | Layer | Source | Behavior | | -------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------- | | 1. First-Loss Buffer | Protocol-owned stablecoin reserve | Absorbs the first tranche. If a prior incident depleted it, only the remaining balance is available | | 2. Vault slashing | Staker collateral | Absorbs the rest, pro-rata across positions, denominated in USD at the slash instruction | Vaults are never slashed beyond the instruction amount. Staker downside is bounded, and stakers cannot be forced into negative equity. Anything the buffer and slash cannot cover passes through to the beneficiary as a shortfall. A payout that only partially consumes a Cover Token leaves the remaining coverage in force for the rest of the period. ### Liquidation execution Slashed collateral is routed to the Liquidation Execution Service, which unwraps staked assets, such as `stXRP -> XRP`, and sells into payout currencies. Payouts are made in approved, audited stablecoins published on-chain. The Cover Token's preferred currency is filled first; if liquidity is short, the protocol falls back through the supported set or splits across currencies. Entitlement is always denominated in USD. Currency preference governs denomination, not the amount owed. At MVP, distribution to beneficiary addresses is performed manually by the Firelight Network multisig. Automated on-chain claiming is planned after MVP. Execution strategy scales with slash size: | Slash size | Strategy | | ------------ | ------------------------------------- | | `< $5M` | Exchange TWAP or VWAP | | `$5M–$25M` | OTC primary plus exchange residual | | `$25M–$100M` | Multi-OTC plus exchange TWAP | | `> $100M` | Syndicated OTC plus structured unwind | ### **Shortfalls** A beneficiary can receive less than the approved loss in three cases: a prior incident has already consumed payout capacity, collateral value declines before liquidation completes, or execution slippage reduces proceeds. In each case the shortfall is shared pro-rata - every beneficiary in the incident takes the same percentage reduction. The slash amount is fixed at the moment it is instructed. The protocol does not draw additional buffer or slash further collateral to cover execution friction, so staker downside is bounded and known at instruction time. If execution underperforms, the shortfall passes to beneficiaries; if it overperforms, the excess returns to the vault rather than topping up payouts. Execution strategy and the recovery process are designed to keep these outcomes rare and small. ### **Recovery** Settlement opens a recovery window, the length of which is published before launch. Assets recovered after payout — through white-hat return, law-enforcement action, or protocol-level recovery — flow back through the waterfall in reverse order of absorption: stakers are made whole first, and any remainder replenishes the First-Loss Buffer. The Firelight Network manages the recovery process off-chain. ### Where to read next * [Claims Process](/for-program-operators/claims-process) for the incident timeline. * [Risk and Exposure](/for-stakers/risk-and-exposure) for the staker-side view of vault slashing. # Resources This section collects reference material for Firelight Coverage: the FAQ, a glossary of terminology, security and audit information, and the key links. ### What you'll find here * [FAQ](/resources/faq) answers common questions about coverage products, eligibility, claims, and the staking model. * [Glossary](/resources/glossary) defines the terms used across the documentation, including the foundational Phase 1 staking terms (FAssets, FXRP, FLR, Launch Vault, stXRP). * [Audits and Security](/resources/audits-and-security) lists audits relevant to the coverage protocol and the foundational launch-vault contracts. * [Links & Contact](/resources/links-and-contact) collects official channels, the full cover terms link, partner references, and developer resources. * [Terms of Participation](https://firelight.finance/terms-of-participation) sets out the terms and conditions governing participation in Firelight’s coverage protocol. ### Phase 1 reference material has been merged in Firelight Phase 1 had its own FAQ, glossary, and resources. Those pages are being retired as the coverage protocol (Phase 2) goes live, and the reference material that remains useful has been merged into this section. Specifically, the Phase 1 staking glossary terms now appear in the Glossary, the launch-vault audit list is the canonical home in Audits and Security, and the "how to obtain stXRP" walk-through is folded into [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals) under Stakers. # 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). ### 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) 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). 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). 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). ### 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). #### 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). #### 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). #### 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 Firelight Networks override the consortium? No. The consortium's vote is binding subject to the 3-of-5 quorum and approval threshold. Firelight engages members but does not direct their decisions. # Glossary Definitions of terms used across this documentation. The Phase 1 staking glossary terms (FAssets, FXRP, FLR, Launch Vault, stXRP) have been merged into this glossary, and the Phase 1 pages are no longer maintained. #### Approved market A chain, protocol, and market combination, with an optional pool identifier for DEX positions, that has passed risk assessment and is listed in the Cover Registry as eligible for coverage. #### Auto-inclusion The model by which Firelight identifies every active Cover Token exposed to a confirmed incident and includes the valid ones in the payout set automatically, without a program-operator-submitted claim. #### Available limit The coverage capacity remaining for a given protocol in the current period, published in the Cover Registry. #### Bad-debt expected loss The component of economic risk that captures the near-term probability and severity of a bad-debt incident on a covered market. One of the two components of the economic view. The other is the [graph overlay](#graph-overlay). #### Base premium emissions The market-level premium, as a percentage of coverage, published in the Cover Registry and refreshed every 30 days. It reflects Firelight's monitored risk view for that market. #### Beneficiary The address recorded on a Cover Token that receives any payout for that token. In the MVP, it is expected to be controlled by the program operator. #### Blocklist The compliance mechanism preventing specified addresses from deploying, withdrawing, or transferring. Authorized roles can rescue assets from blocklisted accounts to a non-blocklisted address. #### Capital Adequacy Ratio (CAR) The ratio of Available Capital to the Solvency Capital Requirement. The matching engine will not allocate capacity that would push CAR below its floor. #### Claims Registry The on-chain contract that records confirmed incidents, the auto-included coverage set, Risk Consortium votes, and slash instructions. It replaces the older submit-and-escrow claims flow. #### Collateral contagion A module of the [graph overlay](#graph-overlay) that asks whether fragile collateral, for example collateral with recognized structural backing dependencies, can drain liquidity from the loan tokens it backs and transmit stress upward. #### Composite risk score A display blend of the [economic risk](#economic-risk) view and the [technical risk](#technical-risk) view, used for ranking and presentation. The composite is a presentation aid. Pricing uses the underlying economic and technical split, not the composite. #### Coverage Schedule The per-enabled cover schedule listing covered markets, allocated amounts, and any sublimits applying to economic-risk coverage. #### Cover Agent The on-chain contract that handles quoting, premium pull-through, and coverage-token issuance when a program operator enables cover on a vault. #### Cover Registry The on-chain registry publishing per-market parameters: base premium rate and available limit per protocol. Refreshed every 30 days. #### Cover Token An ERC-721 token representing an active coverage position. It encodes covered markets, coverage amount, rate, premium, and period. It is held in the program operator's wallet throughout the period and used as the on-chain record for payout eligibility. #### Curator The entity that designs the strategies of the underlying vaults that program operators offer, under a commercial arrangement. The same entity also acts as the protocol's curator in the incident lifecycle: it opens incidents on-chain and prepares the proposed loss schedule that the Risk Consortium validates. A curator can be the same entity as the program operator or a distinct commercial partner for strategy design; the incident-curation function is performed by the protocol's designated curator. #### Diversification Factor (DF) A score reflecting portfolio diversification. It multiplies Nominal Leverage to produce Effective Leverage. Higher diversification allows higher effective leverage. #### Economic risk The market-driven view of risk: leverage, liquidity stress, collateral fragility, liquidation failure, and structural relationships between collateral and loan tokens. It is built from two components, the near-term [bad-debt expected loss](#bad-debt-expected-loss) and the [graph overlay](#graph-overlay), and priced independently of [technical risk](#technical-risk). #### Effective Leverage Nominal Leverage × Diversification Factor. The ratio at which available capital can back coverage, bounded by a floor and ceiling. #### End user (vault depositor) A depositor in a program operator's vault. End users do not interact with Firelight directly. They benefit from coverage through proceeds the program operator passes through under the operator's vault terms. #### Exploit report The on-chain report published by the independent security partner that confirms an incident and provides the evidence base for consortium validation. Target publication: 48 hours from incident confirmation. #### FAssets Flare's framework for representing non-smart-contract assets, such as XRP, as ERC-20 tokens on Flare. It is the mechanism by which XRP is wrapped into [FXRP](/introduction/how-firelight-works), which is then used as the base asset for [stXRP](/introduction/how-firelight-works) staking. #### Fee Distributor The on-chain contract that distributes premiums and vault boost emissions into an auto-compounding stream routed to stXRP. #### Firelight Networks The entity that stewards Firelight Protocol. It holds protocol treasury, including the First-Loss Buffer, and engages the Risk Consortium and service providers. It does not direct consortium decisions, hold end-user funds, or control end-user payouts. #### Firelight Points A loyalty and engagement measure carried over from Phase 1. Points accrue based on amount staked and time held, with periodic boosts. They are not a claim on premium income. #### First-Loss Buffer A protocol-owned stablecoin reserve that absorbs the first tranche of validated claim losses, ahead of any staker slashing. It is the first of two layers in the loss waterfall. #### FLR The native token of the Flare network. Used for gas on Flare and for certain delegation operations relevant to the FAssets system. #### FXRP The Flare-native ERC-20 representation of XRP, minted via [FAssets](/introduction/how-firelight-works). FXRP is the underlying asset deployed into the Firelight protocol when a staker stakes XRP-denominated capital. #### Graph overlay The structural component of the [economic risk](#economic-risk) view. It watches relationships between collateral assets and the loan tokens they back, and produces an additional expected loss where supported. The overlay has two named modules: [liquidity entrapment](#liquidity-entrapment) and [collateral contagion](#collateral-contagion). #### Incident A confirmed exploit or covered failure recorded on-chain. Opening an incident freezes the exposed Cover Token set and pauses stake deployments. Each incident moves through detection, reporting, assessment, settlement, and closure. This replaces the older term "event." #### Launch Vault The original Firelight vault contract that holds FXRP and issues stXRP. It launched in Phase 1 and now forms part of the Firelight Vault's underlying machinery in Phase 2. Audits of the Launch Vault are the foundational audits inherited by the coverage protocol; see [Audits and Security](/resources/audits-and-security). #### Liquidity entrapment A module of the [graph overlay](#graph-overlay) that asks whether borrowers have consumed so much of a loan token's available liquidity that lenders may be effectively trapped, even before a bad-debt incident is realized. #### Loss waterfall The sequence of loss-absorbing layers activated on a validated claim: First-Loss Buffer, then vault slashing. #### Matching engine The off-chain service that allocates coverage capacity at each period boundary: renewals first, then new orders, pro-rated under oversubscription, with premiums pulled via approvals and Cover Tokens issued for matched orders. #### Nominal Leverage Total active coverage divided by available capital, before adjusting for diversification. #### Non-vote A consortium member's declaration that they will not participate in a specific incident vote due to a conflict of interest. It is recorded on-chain and not counted toward quorum. #### Payout capacity The single value that bounds every payout: the First-Loss Buffer plus the market value of staked assets, measured at settlement. If an approved loss exceeds payout capacity, beneficiaries share what is available pro-rata. #### Period A fixed 30-day cycle to which coverage, pricing, and capacity all align. Cover is enabled and renewed at period boundaries. Formerly called an epoch. #### Phase 1 (launch phase) Firelight's initial release: single-asset stXRP staking via the [Launch Vault](/core-concepts/vault-architecture), backed by XRP through [FXRP](/introduction/how-firelight-works) on Flare. Documentation for Phase 1 is being retired and its still-useful reference material has been merged into the Phase 2 docs. #### Phase 2 (Coverage) Firelight's feature-complete release and the scope of this documentation set. It is the on-chain coverage protocol: program operators elect cover on the vaults they run, stakers back coverage, the Risk Consortium validates incidents, Cover Tokens represent active coverage, and the payout waterfall settles validated claims. #### Program operator The institutional entity that elects cover on a vault it runs, holds the on-chain [Cover Token](/for-program-operators/cover-tokens), and receives any payout from the protocol on a validated incident, then passes proceeds through to its [end users](/for-stakers) under the vault's terms. In the MVP, program operators are permissioned and complete onboarding before they can elect cover. #### **Reconciliation window** The second phase of the unstaking window: the full cover period after the period in which the unstake was initiated. Capital in reconciliation 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. #### Recovery bounty The share of post-payout recovered assets paid to Risk Consortium members who actively contribute to a recovery. Remaining recovered assets flow back through the loss waterfall in reverse order of absorption. #### Risk Committee The Firelight body that approves markets for coverage, sets concentration limits, and calibrates the parameters of the risk and pricing framework. It is distinct from the Risk Consortium, which validates incidents. #### Risk component One of the four groupings of risk Firelight monitors in real time, blockchain, protocol, asset, and strategy, used to organise signals within both the economic and technical views. #### Risk Consortium The independent body engaged by the Firelight Networks to validate incidents against published coverage criteria and signal the outcome on-chain. It launches with five confirmed members, operates at arm's length from Firelight Networks and commercial service providers, and uses a 3-of-5 quorum. #### Risk mode The treatment applied to an internal pricing unit, the [strategy row](/risk-and-pricing-model). One of `blended`, `economic_only`, or `technical_only`. #### Settlement cooldown The 12-hour window after a distribution's Merkle root is published and before funds move, providing a final validation window during which a distribution can be cancelled. #### Slashing The pro-rata reduction of staker vault positions to fund a validated claim payout, applied only after the First-Loss Buffer is exhausted. #### Solvency Capital Requirement (SCR) The capital the protocol must hold against its in-force coverage. It reflects a coverage-over-leverage component and a portfolio expected-loss component drawn from the live economic and technical views. #### Strategy row The internal pricing unit that decomposes a vault's coverage into named strategies, each connecting a covered exposure amount to the market that drives its economic risk and the protocol or chain that drives its technical risk. It carries a [risk mode](#risk-mode). Program operators see their policy at the market level rather than at the row level. #### stXRP The staking token issued by the Firelight vault in exchange for [FXRP](/introduction/how-firelight-works). It represents a staker's proportional position in the vault and accrues the underlying protocol base rate emissions plus protocol-related rewards. Originally introduced in Phase 1 as the launch staking product, the same token now backs Phase 2. #### Technical risk The code- and infrastructure-driven view of risk: smart-contract bugs, oracle and integration fragility, upgrade patterns, and chain-level settlement behavior. It is scored separately from [economic risk](#economic-risk) and aggregated into its own portfolio expected-loss view. #### **Unstaking window** The interval between initiating an unstake and the underlying becoming withdrawable: the remainder of the current period plus one full period. #### Watchlist The state applied to a market showing concerning indicators: new-coverage capacity freezes, monitoring frequency increases, and Risk Committee review is triggered if the status persists. # Audits and Security Security is central to a coverage product. If the protocol itself is exploited, it cannot credibly protect the positions it covers. This page collects audit and security resources for Firelight. ### **Phase 1: Launch Vault Audits** * [OpenZeppelin - smart contract audit](https://github.com/firelight-protocol/firelight-core/blob/main/audits/2025-07-21_OpenZeppelin_Firelight.pdf) * [Coinspect - frontend audit](https://github.com/firelight-protocol/firelight-core/blob/main/audits/2025-09-01_Coinspect_Firelight_Frontend.pdf) * [Immunefi - audit competition](https://github.com/firelight-protocol/firelight-core/blob/main/audits/2025-12-01_Firelight_Audit_Competition_Summary_Report.pdf) ### **Phase 2: Feature-Complete Launch** * Audits coming soon. ### Bug bounty program Firelight maintains an active bug bounty program covering deployed coverage contracts, integrations with external custody and liquidation venues (where Firelight code is involved), and off-chain services that write to on-chain state under authorized roles. Reports should be submitted through the official bounty channel rather than disclosed publicly. ### Monitoring integrations The protocol integrates with third-party monitoring infrastructure for real-time incident detection. Covered protocols are required to participate in this monitoring as a condition of coverage. Alerts feed the Claims Registry and the Risk Consortium when an incident is detected. ### External dependencies Firelight's security posture depends on several external components: the host chain, oracle infrastructure, custody providers, and liquidation counterparties. Due diligence on these is part of the Network's ongoing responsibility, and incidents at any of these layers are reflected in the monitored risk view for affected markets. ### Incident response If an incident affects the coverage protocol itself (rather than a covered protocol), active operations may be paused to contain the issue, the Network coordinates with service providers and auditors to assess scope, affected participants are notified through official channels, and a post-mortem is published once remediation is complete. Pausing is reserved for genuine emergencies, not routine operations. ### Where to read next * [Links & Contact](/resources/links-and-contact) for the bug bounty channel and full cover terms. # Links & Contact Official channels, key documents, and developer resources for Firelight Coverage. ### Cover terms The complete, legally binding cover terms are published to IPFS and are the authoritative source for definitions, conditions, and the full exclusions list. Each Cover Token references the applicable terms via its `termsURI`. {% hint style="info" %} The direct IPFS link to the full cover terms document will be published here closer to launch. {% endhint %} ### Risk Consortium The consortium launches with five confirmed members: Hypernative, Cyfrin, Credora, GFX Labs, and Native. {% hint style="info" %} Member logos and a direct link to the Risk Consortium page on the Firelight website will be added here. {% endhint %} ### General inquiries and support Start with the official Firelight channels maintained by the Network . Authoritative channel URLs are listed below. The Phase 1 Resources page is no longer maintained. | Channel | Purpose | | ------------------------------------------------ | ----------------------------------------------------------- | | [Discord](https://discord.com/invite/m9APzp5KrJ) | Community discussion, general questions, ecosystem updates | | [X / Twitter](https://x.com/Firelightfi) | Protocol updates, news, ecosystem content | | [Blog](https://medium.com/@Firelight) | Long-form content, launch announcements, technical writeups | ### Coverage-specific inquiries | Topic | Where to go | | --------------------------------------------------- | ---------------------------------------------------------------------------- | | Institutional coverage onboarding | Contact form on the main Firelight site | | Protocol integration requests (new market listings) | Contact form on the main Firelight site, referencing the protocol and market | | Risk Consortium inquiries | Direct outreach via the Network 's contact channel | | Security disclosures | Official bug bounty submission channel (not public channels) | Because coverage enablement is permissioned in the MVP, institutional program operators should begin with the onboarding contact form rather than public channels. ### Building on Firelight Developers and protocol teams integrating with Firelight Coverage can review [Protocol Architecture](/protocol-architecture) for the coverage-specific components, and reach out through the partnerships channel for structured engagement. A public developer portal with full ABIs and integration guides is on the roadmap. ### Staying up to date Major protocol changes, new approved markets, parameter adjustments, governance actions, material incidents, are announced through the official channels above. # Brand Assets Download Firelight’s official logos, brand guidelines, and visual assets for consistent and accurate representation. Access Firelight’s official brand guidelines, including logo usage, typography, colors, and visual standards. Download Brand GuidelinesDownload Firelight Logo