Risk Analysis Platform

Risk Score Framework

1. Overview

Our Risk Score Framework provides a comprehensive, quantitative assessment of DeFi protocol risk across multiple dimensions. The framework evaluates protocols using over 40 individual formulas organized into 9 major risk categories. Each formula produces a score on a 1-5 scale, where 1 represents the highest risk and 5 represents the lowest risk. These individual scores are then weighted according to protocol type and aggregated into a final normalized score from 0 to 100.

The scoring methodology is designed to be transparent, reproducible, and tailored to different protocol categories including Stablecoins, Lending protocols, Liquid Staking Tokens (LST/LRT), Real World Assets (RWA), Derivatives, DEXs, and Bridges. Each protocol type has a customized weight matrix that reflects the relative importance of different risk factors for that specific category.

2. Blockchain Risk

Blockchain risk assesses the underlying infrastructure security and decentralization properties of the chain on which a protocol operates. This category comprises four key metrics:

BC1: Blockchain Type - Evaluates the fundamental architecture, scoring L1 chains highest (5), followed by Sidechains (4), Based L2s (3), ZK Rollups (2), and Optimistic Rollups (1).

BC2: Nakamoto Coefficient - Measures network decentralization by counting the minimum number of entities needed to compromise the network. Scores range from 1 (highly centralized, coefficient < 3) to 5 (highly decentralized, coefficient > 15).

BC3: Chain Maturity - Assesses the stability and battle-testing of the blockchain based on its operational history.

BC4: Chain Lindyness (TVL Stability) - Evaluates chain-level TVL stability over 180 days using a sophisticated formula combining statistical measures with chain ranking. The formula calculates a stickiness metric and applies a scale factor based on the chain's TVL rank. The coefficient of variation is calculated as:

CV = \frac{\sigma}{\mu}

where

\sigma

is the standard deviation and

\mu

is the mean TVL.

3. Protocol Risk

Protocol risk encompasses 11 individual metrics that evaluate the protocol's code quality, security posture, operational track record, and design architecture. Key formulas include:

P1: Code Nature - Categorizes protocols from established forks (higher score) to novel custom implementations (lower score).

P3: Exploit History - Measures time since deployment without major security incidents.

P4: Auditing Coverage - Evaluates the quality and comprehensiveness of security audits and bug bounty programs.

P5: TVL Lindyness - Similar to BC4 but applied at the protocol level. The formula computes:

\text{stickiness} = \text{clamp}\left(1 - CV + \text{bonus}, 0, 1\right)

The bonus factor accounts for TVL directionality using linear regression slope analysis. A positive slope (growing TVL) adds up to +0.15, while negative slope subtracts up to -0.15. The final score applies a scale factor based on absolute TVL ranges ($1B+,

500M+,

250M+, $50M+).

P6: Oracle Architecture - Assesses oracle dependency and design, with multi-source oracles scored highest.

P8: Redemption Dynamics - Evaluates the quality and reliability of exit mechanisms.

P9: Funds Management - Scores custody models and on-chain verifiability of fund movements.

4. Governance Risk

Governance risk evaluates the centralization and security of protocol upgrade mechanisms and decision-making processes:

G1: Upgrade Process - Scores immutable contracts highest (5), followed by DAO-governed (4), multisig-controlled (3), and EOA-controlled (1).

G2: Governance Power Distribution - Measures token distribution and voting power concentration using Gini coefficient-style analysis.

G3: Timelock - Evaluates the delay period before governance changes take effect, providing users time to exit if they disagree with proposed changes. Longer timelocks receive higher scores.

5. Subsector Risks

Bridge Risk (B1-B2)
Bridge design architecture and cross-chain execution delays are critical for protocols that move assets between chains. Native bridges score highest, followed by lock-mint designs and liquidity networks.

Stablecoin Risk (S1-S5)
The most complex formula in our framework is S1: Peg Stability, which uses a weighted 4-component model:

S1 = 1 + \left(0.4 \cdot c_1 + 0.35 \cdot c_2 + 0.15 \cdot c_3 + 0.1 \cdot c_4\right) \times 4

where $c_1

measures time within ±1% of peg (40% weight),

c_2

evaluates P95 deviation (35% weight),

c_3

assesses P99 deviation (15% weight), and

c_4$ captures average skew (10% weight). Other stablecoin metrics evaluate liquidity depth, backing nature (fiat, crypto, algorithmic, hybrid), regulatory compliance, and parameter governance.

CDP/Collateral Risk (CDP1-CDP3)
Collateralized Debt Position protocols are assessed on collateral quality, liquidation mechanism design, and whether collateral is isolated or pooled.

Lending Risk (L1-L3)
Lending protocols are evaluated on their fundamental model, collateralization requirements, and parameter governance.

LST/LRT Risk (LST1-LST3)
Liquid staking derivatives face unique risks from validator slashing, operator centralization, and operator capital at risk.

RWA Risk (RWA1-RWA2)
Real World Asset protocols are scored on legal ownership structure and asset transparency/auditability.

Derivatives Risk (D1-D4)
Derivatives protocols require robust backstop mechanisms, collateral isolation, position limits, and trustworthy matching engines.

6. Weight Matrix

Each protocol type has a customized point allocation totaling 500 points distributed across applicable formulas. For example, Stablecoin protocols allocate:

• Blockchain Risk (10%): 50 points across BC1-BC4
• Protocol Risk (35%): 175 points across P1-P11
• Governance Risk (10%): 50 points across G1-G3
• Bridge Risk (5%): 25 points across B1-B2
• Stablecoin-Specific Risk (40%): 200 points across S1-S5 and CDP1-CDP3

Different protocol types emphasize different risk dimensions. For instance, LST/LRT protocols allocate more weight to operator-related metrics (LST1-LST3), while lending protocols prioritize collateralization models and parameter governance. Formulas that receive 0 points for a given protocol type are skipped entirely in that protocol's score calculation.

7. Score Aggregation

The final 0-100 score is calculated through a multi-step process:

Step 1: Weighted Sum
For each applicable formula, multiply the individual score (1-5) by its assigned weight (points):

\text{weighted score} = \text{formula score} \times \text{weight}

Step 2: Handle Missing Data
When data is unavailable for certain formulas, we scale up proportionally:

\text{scale factor} = \frac{\text{total weight}}{\text{active weight}}

\text{adjusted raw score} = \text{raw score} \times \text{scale factor}

Step 3: Normalize to 0-100
The theoretical minimum score is 500 (all formulas score 1) and maximum is 2,500 (all formulas score 5). We normalize to 0-100:

\text{normalized score} = \frac{\text{adjusted raw score} - 500}{2500 - 500} \times 100

The final score is clamped to the range [0, 100].

8. Data Sources

Our scoring system combines manual inputs with automated data collection:

Manual Inputs - Code nature, audit reports, governance mechanisms, team transparency, and other qualitative factors are assessed through research and entered manually.

Automated Data - TVL metrics, price data, liquidity depth, and on-chain parameters are fetched from APIs including DeFiLlama, 0x, CoinGecko, and direct blockchain queries. Historical data for lindyness calculations covers the past 180 days (6 months).

Update Frequency - Automated metrics are refreshed daily, while manual assessments are reviewed quarterly or when significant protocol changes occur. Users can view the last update timestamp for each protocol in the dashboard.

9. Implementation

The framework is implemented with strong type safety and modularity:

Formula Registry - Each formula is registered with metadata including ID (e.g., 'BC1'), category, description, and applicable protocol types.

Calculator Pattern - Individual calculators in /lib/scoring/ encapsulate the scoring logic for each formula, accepting typed inputs and returning normalized 1-5 scores.

Service Layer - The aggregation service in /lib/services/formulas/ orchestrates score calculation, applying the weight matrix and handling missing data.

Type Safety - All inputs, outputs, and intermediate calculations use TypeScript interfaces to prevent type errors and ensure consistency.

This architecture ensures the scoring framework remains maintainable, testable, and auditable as it evolves.

Protocol Risk Framework

Last updated

Search protocols...

Most Secure Subsector

Least Secure Subsector

Average Score (All Protocols)

Pain Point Per Subsector

of --