> 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/technical-scoring.md).

# Technical Scoring

The technical side of Firelight's risk view measures the code- and infrastructure-level risk of each market. This page describes, at a high level, the signals Firelight monitors and how they are kept current. It is a reference companion to the [Risk Pricing Framework](/core-concepts/risk-pricing-framework.md).

### What technical monitoring covers

Technical monitoring focuses on objective, verifiable properties of the underlying code and infrastructure:

* Security review history (audit recency, scope, and firm quality)
* Known vulnerabilities and exploit history
* Code quality and complexity
* Infrastructure robustness and uptime
* Admin controls, upgradeability, and key management
* Operational maturity (time live on mainnet without critical incident)

It does not cover market dynamics, governance behavior, or liquidity, those are economic signals (see [Economic Model](/risk-and-pricing-model/economic-model.md)).

### Signals by component

The protocol monitors representative technical signals at each risk component:

| Component  | Example technical signals                                                                                                                     |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Blockchain | Validator/node decentralization, finality, client and consensus audits, incident history                                                      |
| Protocol   | Audit count and recency, audit-firm quality, exploit history, bug bounty, upgradeability and admin keys, oracle dependencies, code complexity |
| Asset      | Token-contract audits, token-mechanics complexity, issuer integrity for wrapped assets, historical incidents                                  |
| Strategy   | Strategy-contract audits, composability surface, liquidation-logic clarity, upgrade governance                                                |

### How signals are kept current

Signals are sourced continuously from a mix of on-chain data (contract code, deployment history, admin-key structures, upgrade incidents, oracle dependencies), public audit reports, bug-bounty program details, and incident databases. Data freshness matters: stale inputs are refreshed before they inform pricing, or flagged so the protocol can take a conservative stance.

This continuous refresh is what makes the technical view a live signal rather than a one-time score. As a protocol's technical posture changes, a new audit lands, an exploit is disclosed, an admin key is rotated, the monitored view updates and feeds the next period's published rate.

### Technical signals can gate eligibility directly

Some technical findings remove a market from coverage regardless of everything else:

* No audit covering the current codebase.
* An active exploit or critical vulnerability disclosed.
* An admin-key structure without a meaningful threshold or timelock (absent compensating controls).
* Code never audited by a recognized firm.

These rules prevent a protocol with obvious technical issues from being backed even when other factors look attractive.

### How the technical view feeds pricing

The monitored technical signals roll up into a per-market technical risk view that the protocol uses two ways:

* **Per-market pricing.** A higher monitored technical risk raises the technical contribution to that market's premium, independently of the economic view.
* **Portfolio technical expected loss.** The technical view across all covered markets aggregates into a portfolio-level technical expected loss, which feeds capital adequacy alongside the economic expected loss (see [Capital Adequacy](/risk-and-pricing-model/capital-adequacy.md)).

The technical view runs as a separate track from the economic view. For blended rows it adds to the economic contribution, and for the rare technical\_only row it is the only driver. The two views also blend into a **composite risk score** for display and ranking, which sits alongside, not on top of, the underlying split that pricing actually uses.

### Where to read next

* [Economic Model](/risk-and-pricing-model/economic-model.md) for the market- and governance-level signals.
* [Risk Pricing Framework](/core-concepts/risk-pricing-framework.md) for how monitored risk becomes a price.


---

# 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/technical-scoring.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.