> 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/protocol-architecture/on-chain-components.md). # 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.md). 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.md). 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.md) for the services that feed the on-chain surface. * [Claims Liquidation](/protocol-architecture/claims-liquidation.md) for what happens after a validated slash. --- # 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/protocol-architecture/on-chain-components.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.