Feature Proposal: Risk-Adjusted TVL Quality Score for Better Protocol Evaluation

[AntipasBen23]

Problem Statement

Current TVL metrics treat all locked value equally, regardless of underlying protocol risks. A protocol with $1B TVL behind a 2/3 multisig appears identical to one with fully decentralized governance. This creates a false sense of security and doesn't help users make informed decisions.

Recent events (Terra, FTM, various rug pulls) have shown that high TVL ≠ safety. Users need better risk-adjusted metrics.

Proposed Solution

Introduce a Risk-Adjusted TVL metric that factors in protocol security characteristics:

Risk-Adjusted TVL = TVL × (1 - weighted_risk_score)

Risk Factors to Consider:

• Admin key control (EOA vs multisig vs timelock vs fully immutable)
• Oracle dependencies (Chainlink vs TWAP vs custom)
• Upgradeability patterns (proxy patterns, pause mechanisms)
• Liquidity concentration (% from top 10 wallets)
• Smart contract maturity (time since deployment, audit status)
• Bridge/external dependencies

Implementation Plan

Phase 1: Risk Schema (Week 1)

• Add riskProfile field to protocol metadata
• Define standardized risk categories and weights
• Create documentation for risk methodology

Phase 2: Initial Data (Week 2-3)

• Manually assess top 50 protocols by TVL
• Create risk scoring rubric
• Add risk data to adapters

Phase 3: Frontend Integration (Week 4)

• Add toggle: "Show Risk-Adjusted TVL"
• Risk badge on protocol cards
• New sorting option in rankings

Phase 4: Automation (Future)

• On-chain monitoring for admin key changes
• Automated risk score updates
• Community contributions for risk assessments

Value Proposition

• For DeFiLlama: Differentiated metric no other analytics platform offers
• For Users: Better risk assessment at a glance
• For Protocols: Incentive to improve security practices

Questions for Maintainers

1. Is this aligned with DeFiLlama's vision and roadmap?
2. Any preferred methodology for risk scoring you'd like to see?
3. Would you prefer this as a core feature or separate module?
4. Should risk data be in adapters or a separate repository?

I'm happy to build a proof-of-concept with 5-10 protocols first to demonstrate the value. I can also create a Figma mockup of the UI changes if helpful.

Technical Approach

• Minimal changes to existing codebase
• Backward compatible (risk scores optional)
• Community-contributable via PRs

Looking forward to your thoughts!