> For the complete documentation index, see [llms.txt](https://docs.firelight.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.firelight.finance/resources/glossary.md). # 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 detection. #### 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.md), which is then used as the base asset for [stXRP](/introduction/how-firelight-works.md) staking. #### Fee Distributor The on-chain contract that distributes premiums and vault boost emissions into an auto-compounding stream routed to stXRP. #### Firelight Network 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.md). 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.md). #### 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.md), backed by XRP through [FXRP](/introduction/how-firelight-works.md) 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.md), and receives any payout from the protocol on a validated incident, then passes proceeds through to its [end users](/for-stakers.md) 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 Foundation 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 the Foundation 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.md). 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.md). 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.firelight.finance/resources/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.