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
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
Foundation (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.
An onboarded program operator requests a quote for specified markets and amounts.
Cover Agent queries the Cover Registry and matching engine for available limits.
A quote is returned with per-market rates, a blended rate, premium amount, and validity.
On confirmation and period-boundary matching, Cover Agent pulls premium via the program operator's approval.
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 Foundation 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. 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. 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 for the services that feed the on-chain surface.
Claims Liquidation for what happens after a validated slash.
Last updated