> 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/off-chain-components.md).

# Off-Chain Components

Not everything Firelight does can happen on-chain. Real-time risk monitoring, premium pricing, order matching, and liquidation execution all require data inputs, computation, or external venues that smart contracts cannot access directly. This page covers the off-chain services and how they interface with the on-chain contracts.

### Service summary

<table><thead><tr><th>Service</th><th width="185.80078125">Role</th><th>Output</th></tr></thead><tbody><tr><td>Risk Monitoring Service</td><td>Continuously monitor risk components for each approved market</td><td>A live risk view per market</td></tr><tr><td>Pricing Service</td><td>Translate the monitored risk view into base premium rates and available limits</td><td>Parameters written to the Cover Registry</td></tr><tr><td>Order Matching Engine</td><td>Allocate coverage capacity at period boundaries</td><td>Matched orders, premium pulls, Cover Token issuance</td></tr><tr><td>Payout Calculation Service</td><td>Compute payouts for validated incidents</td><td>Slash instructions</td></tr><tr><td>Liquidation Execution Service</td><td>Convert slashed collateral into payout stablecoins</td><td>Payout stablecoins distributed to Program Operators</td></tr><tr><td>Monitoring and Alerting</td><td>Detect exploit incidents and protocol stress</td><td>Alerts, watchlist updates, exploit reports</td></tr></tbody></table>

### Risk Monitoring Service

The Risk Monitoring Service implements the continuous monitoring described in [Risk Pricing Framework](/core-concepts/risk-pricing-framework.md), [Technical Scoring](/risk-and-pricing-model/technical-scoring.md), and [Economic Model](/risk-and-pricing-model/economic-model.md). It ingests on-chain data, public audit reports, incident data, and market data. It maintains a live risk view per market and flags markets approaching exclusion thresholds for Risk Committee review. Its outputs feed the Pricing Service and are retained for transparency and calibration.

### Pricing Service

The Pricing Service converts the monitored risk view into the on-chain parameters published to the Cover Registry: the base premium rate and the available limit per protocol. It operates under access control, updates to the Cover Registry require signatures from authorized roles and are subject to governance review. Because the underlying risk view is monitored continuously, each period's published rate reflects the latest conditions rather than a stale snapshot.

### Order Matching Engine

The Order Matching Engine runs at each period boundary and implements the two-queue priority system described in [Periods and Coverage Cycles](/core-concepts/periods-and-coverage-cycles.md):

1. Calculate available capacity (First-Loss Buffer + staked collateral value × effective leverage, minus active coverage, minus renewal commitments, plus unstake releases).
2. Process the renewal queue first. Pro-rate if demand exceeds capacity.
3. Process the new-order queue with remaining capacity. Pro-rate if demand exceeds capacity.
4. Pull premiums from prefunded wallets via approvals (partial matches pull proportionally).
5. Route settled premiums to the Fee Distributor.
6. Issue Cover Tokens for matched orders.
7. Refund unmatched premiums.

The engine will not allocate capacity that would drop the Capital Adequacy Ratio below its floor.

### Payout Calculation Service

When the Risk Consortium validates an incident, this service produces the slash instruction the Claims Registry executes: it determines available payout capacity (First-Loss Buffer plus the market value of staked assets, measured at settlement), computes per-enabled coverage payouts (full if within capacity, pro-rata otherwise) across the auto-included set, and accounts for concurrency guards if another slash is in flight on the same vault.

### Liquidation Execution Service

Once collateral is slashed, this service converts it into the payout stablecoins preferred by each Program Operator, using execution strategy scaled to claim size, exchange execution for smaller incidents, OTC and syndicated unwinds for larger ones. It uses regulated venues and counterparties and tracks the slashed collateral value and the realized liquidation proceeds separately.

### Monitoring and Alerting

Continuous monitoring watches for incidents that could result in claims or threaten solvency.

| Alert                   | Trigger                                            |
| ----------------------- | -------------------------------------------------- |
| Critical security alert | Active exploit or critical vulnerability disclosed |
| TVL decline             | Sharp drop over a short window                     |
| Governance change       | Material parameter change or admin-key rotation    |
| Audit finding           | New critical or high-severity finding              |
| Oracle deviation        | Price deviation beyond reference thresholds        |

Markets showing concerning indicators are placed on a watchlist: new-coverage capacity freezes, monitoring frequency increases, and risk review is triggered if the status persists.

### Where to read next

* [On-Chain Components](/protocol-architecture/on-chain-components.md) for the contracts these services feed into.
* [Claims Liquidation](/protocol-architecture/claims-liquidation.md) for the full payout pipeline.


---

# 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/off-chain-components.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.