Skip to main content
This is the V2 risk-score methodology — the 0–100 composite that the V3 vault surface maps to a letter grade. For the V3 framework (seven weighted categories, composite letter grade, criteria taxonomy) see Vault Risk V3. The 0–100 score here is the same value V3 reports as composite.score.
How it works: Every vault gets a 0–100 composite risk score (0 = safe, 100 = critical). It’s built from ~20 sub-scores, each weighted by importance. Additionally, additive penalties and hard state floors can force the score higher for binary danger conditions. A higher score means a riskier vault.
Every number in the score can be traced back to a specific signal. The API exposes the full sub-score breakdown so we can tell a user “this vault scores 78/100 because redemptions are currently closed and the admin key is an EOA with no timelock” — not just a number.

Letter grade

The 0–100 composite maps to a letter grade via the standard grading_scheme=v2 scale (lower risk = better grade): See the full grading contract.

Outputs

Sub-scores

 The weight shows how much it contributes to the final composite.

Contract and Code Quality

Governance and Control

Liquidity and Exit

Performance and Market Behavior

How these sub-scores map to V3 categories

In V3, you’ll see these V2 sub-scores regrouped into seven weighted risk categories. The mapping below is a conceptual correspondence — it shows where each signal appears, not the exact scoring wiring (the V3 composite is computed from its own framework, not by re-bucketing these V2 weights). hack_exploit_history is driven by the additive penalties and risk flags below (for example, recent exploit, ownership transfer, repeated pausing) rather than a single weighted sub-score. chain_infrastructure is reserved and carries no V2 signal today. For details on what each V3 category measures and representative criteria, see What each category measures.

Oracle Type Quality

The oracle sub-score uses a weakest-link model — the worst oracle type found across all of the vault’s underlying markets sets the floor. Oracle quality is scored by type: Additionally: any collateral token with <$5M daily trading volume raises the oracle sub-score floor to 55 (thin_collateral_market flag). Below that volume threshold, a well-capitalised attacker can move the price enough to overborrow against inflated collateral — the pattern behind the Mango Markets and Cream Finance exploits.

Additive Penalties

These fire for specific dangerous combinations or events and add directly on top of the weighted composite. Multiple conditions stack independently.

Interaction Penalties (Compound Risk)

Governance Behavior Penalties (on-chain activity)

State & Structural Penalties

Yield & Liquidity Trap Penalties

Hard State Floors (binary minimums)

These ensure a catastrophic condition can never be masked by a low smooth score. The composite cannot go below these values when the condition is active.

Computed-but-Zeroed Signals

These are calculated and exposed in the API payload but don’t add to the weighted composite — they feed into additive penalties or are surfaced directly for consumers.

Risk Flags

Flags are surfaced in the API alongside the score. Each maps to one or more of the conditions above. Blocking flags (force do_not_list): unverified, redemption_closed, dormant Non-blocking flags: depeg · high_looping_exposure · no_audits · eoa_owner · pause_capable · upgradeable · negative_return · lockup_7d · withdrawal_delay · low_tvl · new_vault · deposit_closed · inactive · subvault · thin_collateral_market · concentrated_borrower · concentrated_depositor · recent_upgrade · unaudited_upgrade · repeated_pausing · ownership_transfer · exchange_rate_spike · exchange_rate_crash · erc4626_donation_risk · reward_dependent_yield · yield_trap · emergency_deposit_cap · shared_collateral_exposure