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.
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).
Signals by component
The protocol monitors representative technical signals at each risk component:
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).
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 for the market- and governance-level signals.
Risk Pricing Framework for how monitored risk becomes a price.
Last updated