Protocol Risk
Protocol risk captures the structural and governance properties of the protocol itself — the vulnerabilities that sit beneath any individual vault's market dynamics. While market risk asks "how fragile is this vault today?", protocol risk asks "how trustworthy is the system it runs on?"
Most institutional risk frameworks never model this dimension. Ozone makes it explicit and quantified.
Six subcategories
Protocol risk is scored across six subcategories. Each contains weighted metrics scored 0.0–1.0. The subcategory scores combine into a single protocol risk score, which contributes to the composite Ozone Score alongside market and oracle risk.
1. Smart Contract & Teams
Evaluates the transparency and accountability of the protocol's development team and on-chain footprint.
| Metric | What it measures |
|---|---|
| Smart contract discoverability | Are all contract addresses (not just token addresses) publicly documented and clearly labelled — on the website, in docs, or in the repository? |
| Team identity disclosure | Is the team public? At least two named individuals with verifiable online presence scores highest; anonymous teams score 0. |
| Responsiveness | How quickly does the team respond to formal security reports? Response within 24h scores 1.0; no response within 72h scores 0. |
Team identity matters because anonymous teams carry a higher exit-risk surface — public accountability is a long-term commitment signal that documented anonymous teams cannot replicate.
2. Documentation
Evaluates the depth and accuracy of technical documentation — the foundation for any independent security review.
| Metric | What it measures |
|---|---|
| Technical whitepaper | Is there a dedicated technical document describing the protocol's mechanics? A basic landing page description does not qualify. |
| Architecture documentation | Are system diagrams, component interactions, and data flow documented? |
| Code documentation | Are functions and modules commented? Is the codebase navigable by an external auditor without asking the team? |
| Traceability | Can documentation claims be traced back to on-chain code? Undocumented divergences between docs and implementation are flagged. |
| Informativeness | Does documentation actually explain the risk model, parameter choices, and limitations — or just describe features? |
3. Testing
Evaluates the rigour of the protocol's quality assurance process.
| Metric | What it measures |
|---|---|
| Test-to-code ratio | What fraction of the codebase is covered by tests? |
| Test coverage | Are edge cases, failure paths, and adversarial scenarios explicitly tested? |
| Test reports | Are test results publicly available and recent? |
| Formal verification | Has any portion of the critical codebase been formally verified (e.g., using Certora, Halmos, or equivalent)? |
Formal verification adds a small bonus where present — it provides mathematical guarantees that testing alone cannot, though it carries the lowest weight among the four testing metrics.
4. Security
Evaluates the protocol's defences against active exploitation.
| Metric | What it measures |
|---|---|
| Protocol auditability | Has the codebase been audited by reputable, independent firms? How recently, and does the audit cover the current deployment? |
| Audit applicability | Does the published audit actually apply to the deployed code, or is it from a prior version with significant changes since? |
| Bug bounty program | Is there a live, scoped, and funded bug bounty? Immunefi or equivalent with meaningful payout caps scores highest. |
| Protocol monitoring | Is there on-chain monitoring for anomalous activity (e.g. via Hypernative, Forta, or equivalent)? |
| Front-end monitoring | Are DNS hijacking and front-end compromise vectors actively monitored? |
An audit from two years ago that precedes a major contract upgrade is effectively no audit. Ozone accounts for this via the Audit applicability metric above.
5. Admin Controls & Governance
Evaluates who can change the protocol and how.
| Metric | What it measures |
|---|---|
| Code mutability | Can smart contract logic be upgraded? Is upgradeability timelocked, multisig-gated, or fully immutable? |
| Upgradeability documentation | If the protocol is upgradeable, is the upgrade process documented, tested, and publicly visible? |
| Role clarity | Are privileged roles clearly defined and documented? Can an independent auditor determine who can do what? |
| Distinct human signers | For multisig-controlled parameters, how many distinct humans (not addresses) are required? |
| Transaction signing policy | Is there a documented policy for what requires multisig sign-off vs. what can be executed unilaterally? |
Upgradeability is not inherently bad — timelocked, multisig-gated upgrades with community review are the standard for major protocols. What matters is whether the mechanism is documented, auditable, and resistant to a single point of compromise.
6. Oracles (protocol documentation quality)
This subcategory measures whether the protocol itself documents its oracle usage clearly. It is independent of the Oracle Risk score, which measures the on-chain reliability of the actual price feeds.
A protocol that clearly documents that it uses no on-chain oracles (e.g. institutional lending with off-chain custody) can score 100% here. Its Oracle Risk score is a separate question answered separately.
| Metric | What it measures |
|---|---|
| Oracle documentation | Does the protocol document which oracle contracts it uses, why, and what assumptions it makes about their reliability? |
| Flash loan robustness | Does the protocol document its defences against oracle manipulation via flash loan attacks? |
How protocol risk combines with other dimensions
Protocol risk is one of three dimensions in the composite Ozone Score. It combines with market risk and oracle risk via geometric mean:
Ozone Score = (market_score × oracle_score × protocol_score)^(1/3) × 10
In practice, well-established protocols (Morpho, AAVE, Maple Finance) tend to score strongly on protocol risk — they have public teams, extensive audits, live bug bounties, and active governance. The protocol risk dimension most differentiates across newer protocols or those with weaker documentation practices.
See How Ozone Scores Work for the full score composition methodology.