> 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/for-program-operators/how-coverage-works.md).

# 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.md).

### 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.md) 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

<figure><img src="/files/JrNyMBaTyfCU2kAWfn11" alt=""><figcaption></figcaption></figure>

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.md) details the token structure.
* [Pricing](/for-program-operators/pricing.md) explains how the quote is built.
* [Claims Process](/for-program-operators/claims-process.md) covers what happens when a covered incident occurs.


---

# 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/for-program-operators/how-coverage-works.md?ask=<question>&goal=<endgoal>
```

`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.