> 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/core-concepts/risk-pricing-framework.md). # 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](/core-concepts/risk-pricing-framework.md) reference. ### Two views of risk Firelight quantifies all risk parameters in two separate views and prices them independently: | View | What it captures | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **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](/risk-and-pricing-model/technical-scoring.md)). \ 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: | Layer | What Firelight watches | | ---------- | ---------------------------------------------------------------------------------------------- | | 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](/risk-and-pricing-model/capital-adequacy.md)). 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. {% hint style="info" %} 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](/risk-and-pricing-model.md) section and are under active calibration. Published values in the Cover Registry always take precedence. {% endhint %} ### Where to read next * [Coverage Types](/core-concepts/coverage-types.md) lists the specific risk categories that the framework prices. * [Pricing](/for-program-operators/pricing.md) shows how a program operator's quote is built from the published rate. * [Risk and Pricing Model](/risk-and-pricing-model.md) goes deeper for readers who want the methodology. --- # 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/core-concepts/risk-pricing-framework.md?ask=&goal= ``` `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.