Our documentation has been updated with details on Phase 2, how coverage works, claims payouts, and more.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

Service
Role
Output

Risk Monitoring Service

Continuously monitor risk components for each approved market

A live risk view per market

Pricing Service

Translate the monitored risk view into base premium rates and available limits

Parameters written to the Cover Registry

Order Matching Engine

Allocate coverage capacity at period boundaries

Matched orders, premium pulls, Cover Token issuance

Payout Calculation Service

Compute payouts for validated incidents

Slash instructions

Liquidation Execution Service

Convert slashed collateral into payout stablecoins

Payout stablecoins distributed to Program Operators

Monitoring and Alerting

Detect exploit incidents and protocol stress

Alerts, watchlist updates, exploit reports

Risk Monitoring Service

The Risk Monitoring Service implements the continuous monitoring described in Risk Pricing Framework, Technical Scoring, and Economic Model. 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:

  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.

Last updated