Risk Pricing Framework
Firelight prices coverage by monitoring a set of risk parameters for every approved market and updating its view of those components in real time. This page gives a high-level picture of how that works. It is intentionally non-mathematical. The detailed methodology lives in the Risk and Pricing Model reference.
Two views of risk
Firelight quantifies all risk parameters in two separate views and prices them independently:
Economic
Market-driven risk: leverage, liquidity stress, collateral fragility, liquidation failure, and structural relationships between collateral and the loan tokens it backs.
Technical
Code and infrastructure driven risk: smart-contract bugs, oracle and integration fragility, upgrade patterns, and chain-level settlement behavior.
The two views are kept separate on purpose. A market can be economically safe but technically weak, or technically strong but economically fragile, and the pricing engine reflects both.
Economic risk: two components
The economic view itself is built from two complementary components:
A near-term bad-debt view. For each lending market, the protocol monitors how likely a bad-debt incident is over the next 30 days and, if such an incident occurs, how severe the loss would be. This is the day-to-day market-condition view of economic risk.
A structural graph overlay. The overlay watches relationships between tokens. For example, collateral assets and the loan tokens they back, or the reserves of stablecoins and LSTs. For example, lender liquidity being trapped when borrowers consume available liquidity, or fragile collateral draining liquidity from the loan tokens above it.
The bad-debt view and the graph overlay add up to the market's economic risk for pricing purposes.
Technical risk
The technical view scores the protocol and chain's implementation separately from market conditions. It feeds its own portfolio-level expected-loss view (see Technical Scoring). Critical technical findings (a risky code upgrade, an unsafe access control pattern) can remove a market from coverage even when the economic view is clean.
Risk is layered, and monitored continuously
Within each view, signals are organized across the same four layers and refreshed continuously from on-chain data and external feeds:
Blockchain
Network health, finality, validator decentralization, incident history
Protocol
Code comple, Audit status, exploit history, oracle dependencies, governance and admin controls
Asset
Price volatility, liquidity depth, depeg behavior, holder concentration
Strategy
Composition, leverage, liquidation parameters, correlated exposure
The result is a live risk view per market rather than a one-time score.
From monitoring to pricing
The real-time risk view drives three things:
Eligibility. Markets whose monitored risk is too high, or where a critical signal fires (an active exploit, a lapsed audit, a depeg with broken redemption), are not offered coverage.
Premium rate. A higher monitored risk level maps to a higher premium. The premium reflects the protocol's expected cost of covering the market plus the cost of the capital backing it, across both the economic and technical views.
Capacity. The risk view, combined with portfolio diversification, sets how much coverage the protocol will write on a given market (see Capital Adequacy).
Pricing is not static. As the monitored views change between periods, the inputs to the next period's published rate change with them.
The premium is paid by the program operator when it elects cover on a vault. End users do not pay Firelight directly. A program operator may reflect coverage cost in the product economics of its vault.
A composite view for display
Alongside the economic and technical views, Firelight maintains a composite risk score that blends the two into a single view per market for ranking and display. The composite is a presentation aid. It does not replace the underlying split that pricing actually uses.
What the protocol publishes
For each approved market, the protocol publishes a base premium rate and the available limit by protocol to the Cover Registry, refreshed on a 30-day cadence. Within a period the published rate is fixed for program operators. Between periods it can move as the monitored views update.
Detailed mechanics, how signals combine, severity assumptions, the graph overlay's specific paths, and capital adequacy math, are covered in the Risk and Pricing Model section and are under active calibration. Published values in the Cover Registry always take precedence.
Where to read next
Coverage Types lists the specific risk categories that the framework prices.
Pricing shows how a program operator's quote is built from the published rate.
Risk and Pricing Model goes deeper for readers who want the methodology.
Last updated