> 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/risk-and-pricing-model/economic-model.md). # Economic Model The economic side of Firelight's risk view captures market- and governance-based risk for each market. It is built from two complementary components, a near-term bad-debt view and a structural graph overlay, and it drives the economic half of every premium. This page describes both components at a high level. It avoids fixed formulas. Specific assumptions are under calibration. ### How coverage maps to economic risk A vault is not priced as a single block. Firelight decomposes a vault's coverage into **strategy rows**, internal pricing units that connect a named strategy to a covered exposure amount, the market that drives its economic risk, and the protocol or chain that drives its technical risk. Each row also carries a **risk mode**: | Risk mode | Treatment | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `blended` | The row is priced from both the economic and technical views. | | `economic_only` | The row is priced from the economic view only, used where market-driven risk is the dominant exposure. | | `technical_only` | The row is priced from the technical view only, used for raw-holdings sleeves where the primary exposure is the token contract or chain. | Strategy rows and risk modes are internal pricing concepts. Program operators see their enabled coverage at the market level. Decomposing into rows is what lets one vault contain a mix of strategy shapes and still be priced coherently. ### What economic monitoring covers Economic monitoring focuses on dynamics that change with market conditions and participant behavior, rather than on properties of the code itself: * Governance attack surface and decentralization * Price volatility of assets and collateral * Liquidity depth and redemption capacity * Concentration of holders, liquidity, or governance power * Historical market behavior under stress These signals feed both components below. ### Component 1: the near-term bad-debt view The bad-debt view answers two market-level questions for each row's risk market: * If the strategy has lending exposure, how likely is a bad-debt incident over the next 30 days? * If that incident occurs, what fraction of covered exposure might be lost? Together with the row's coverage amount these produce a per-row expected loss from bad-debt risk. The probability and severity are updated continuously from on-chain market state and external feeds, so the next period's published rate reflects the latest conditions rather than a stale snapshot. ### Component 2: the structural graph overlay The graph overlay sits on top of the bad-debt view and captures structural economic risk that the near-term model may not yet see. It is scoped to relationships between collateral assets and the loan tokens those collateral assets back. Where the overlay applies, it produces an additional expected loss for the row, independent of, and additive to, the bad-debt view. The overlay uses two named modules: | Module | What it asks | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Liquidity entrapment** | Have borrowers consumed so much of a loan token's available liquidity that lenders may be effectively trapped, even before a bad-debt incident is realized? | | **Collateral contagion** | Can fragile collateral (for example, collateral with recognized structural backing dependencies) drain liquidity from the loan tokens above it, transmitting stress upward? | The overlay is deliberately narrow today: it scores supported collateral → loan-token paths and produces module-level probabilities and severities that combine into the row's graph-overlay expected loss. New paths and modules are added under Risk Committee review. ### Signals by layer Both components draw from signals organised across the same four layers used throughout the framework: | Layer | Example economic signals | | ---------- | --------------------------------------------------------------------------------------------------------------------------- | | Blockchain | Economic security (stake/market cap securing consensus), censorship resistance, validator concentration | | Protocol | Governance-token concentration, voting participation, delegation diversity, parameter-change velocity, treasury composition | | Asset | Trading volume, realized volatility, liquidity depth, depeg history, holder concentration | | Strategy | Strategy leverage, position concentration, liquidation headroom, correlated exposure | The Cover Registry refreshes on the 30-day cadence, so within a period a program operator's premium is fixed, while between periods the published rate moves as the monitored views change. ### From monitored risk to premium Rather than publishing a pricing formula, the protocol frames pricing as follows: * Higher monitored risk on a market, whether driven by the bad-debt view, the graph overlay, or both, implies a higher expected cost of covering it, and therefore a higher premium. * The premium also reflects the cost of the capital backing the coverage, lower operating leverage requires a higher return per dollar of coverage. * A market whose monitored risk crosses the exclusion line, or where a critical signal fires, is removed from coverage rather than priced. ### How economic and technical views combine Each row carries an economic expected-loss view and, when in `blended` mode, a technical expected-loss view. Both feed the portfolio expected loss that drives capital adequacy (see [Capital Adequacy](/risk-and-pricing-model/capital-adequacy.md)). A **composite risk score** blends the two views for display and ranking. Pricing itself uses the underlying split rather than the composite. {% hint style="info" %} Severity assumptions, the mapping from monitored risk to rate, the specific collateral → loan-token paths supported by the graph overlay, and the weights used in the composite view are actively calibrated and are not published as fixed figures. Cover Registry values take precedence. {% endhint %} ### Where to read next * [Technical Scoring](/risk-and-pricing-model/technical-scoring.md) for the code- and infrastructure-level view. * [Capital Adequacy](/risk-and-pricing-model/capital-adequacy.md) for how the economic and technical views feed portfolio-level capital adequacy. --- # 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/risk-and-pricing-model/economic-model.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.