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.
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 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:
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:
The program operator prefunds the premium amount in their wallet.
The program operator grants the protocol an allowance for the premium in a supported payment asset.
At the period boundary, the protocol pulls the premium amount via the approval.
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.
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.
Matching and issuance
At the next period boundary, the matching engine processes orders in priority order:
Renewals from existing coverage holders are matched first.
Remaining capacity is allocated to new orders.
If any queue is oversubscribed, allocations are pro-rated (by prior-period coverage for renewals. By requested amount for new orders).
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 Foundation Treasury:
Stakers deploy capital into the Firelight Protocol and receive their staked position plus ongoing vault rewards.
The Program Operator sends a quote request and the upfront premium to the Cover Engine + Agent.
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.
Premium flows into the reward pipeline. Part compounds back into the Firelight Vault, raising redemption value for stakers. A portion is routed to the Foundation Treasury as protocol fees.
Foundation 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.
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.
Where to read next
Cover Tokens details the token structure.
Pricing explains how the quote is built.
Claims Process covers what happens when a covered incident occurs.
Last updated