ProtocolWatch Risk Assessment Framework
This framework provides a systematic approach to evaluating DeFi protocols based on their level of decentralization, security practices, and trust assumptions. Inspired by L2Beat's approach to Layer 2 solutions, we categorize protocols into three stages based on objective criteria.
Stage System Overview
Protocols are evaluated across multiple dimensions and assigned to one of three stages. Higher stages indicate lower trust requirements and greater decentralization.
Trustless
Stage 2 protocols operate with minimal trust assumptions. Users can interact with the protocol without trusting any centralized party or governance process with their funds.
Requirements
- Core contracts are immutable OR governed with ≥7-day timelock
- Decentralized governance (if upgradeable)
- No admin capability to directly access or freeze user funds
- Decentralized oracles (or none needed)
- 12+ months of production operation with significant TVL
- Extensive security audits and/or formal verification
- No emergency pause mechanisms that lock funds
Limited Trust
Stage 1 protocols have significant decentralization but still require some trust in governance or admin mechanisms. Users have time to exit before malicious upgrades take effect.
Requirements
- Timelock ≥48 hours on critical upgrades
- Multisig with 3-of-5+ diverse signers OR decentralized governance
- Admin powers clearly scoped and documented
- No direct admin access to user funds (may have indirect upgrade risk)
- At least 2 independent security audits from reputable firms
- 6+ months of production operation
- Oracle dependencies (if any) are decentralized or have fallbacks
Fully Assisted
Stage 0 protocols are functional and may be secure, but require significant trust in centralized parties or admin mechanisms. This is appropriate for early-stage protocols that are still iterating.
Characteristics
- Instant upgrades possible OR very short timelocks (<48 hours)
- Single EOA or weak multisig control (e.g., 2-of-3)
- Admin can access user funds under certain conditions
- Limited or single audit
- Centralized oracle dependencies
- Early stage operation (<6 months)
Risk Dimensions
Each protocol is evaluated across the following dimensions. The combination of these factors determines the overall stage classification.
| Dimension | Description | Key Questions |
|---|---|---|
| Upgradeability | How and when can core contracts be modified | Are contracts immutable? What timelock delays exist? Who can upgrade? |
| Admin Control | Who controls privileged functions | DAO governance, multisig, or EOA? How distributed are signers? |
| Fund Access | Can admins access user funds | Can anyone withdraw user funds? Under what conditions? |
| Audits | Security review depth and quality | How many independent audits? Any formal verification? |
| Oracle | Price feed and data source security | Self-contained, decentralized, or centralized oracles? |
| Track Record | Time in production with real value | How long operating? Any exploits or incidents? |
Methodology
Research Process
Each protocol assessment involves:
- Review of smart contract code and architecture
- Analysis of governance and admin mechanisms
- Examination of security audits and formal verification
- Historical analysis of upgrades and incidents
- Review of oracle dependencies and external integrations
- Community verification and feedback
Limitations
This framework focuses on protocol-level risks (smart contracts, governance, oracles). It does not fully capture:
- Economic attacks and game theory risks
- Composability and integration risks with other protocols
- User interface and operational security
- Regulatory or legal risks
- Market and liquidity risks
Updates
Assessments are updated on a regular basis, and may at times be out of date. Each assessment includes a “Last Updated” timestamp as to let the reader know when the last assessment occurred. TVL figures though are updated daily regardless of what the “last updated” tag says
Disclaimer
The vast majority of the research used to evaluate the stage of a particular protocol has been done by Claude Opus 4.6 and is in most cases NOT manually verified by a human
Contributing
This is an open framework. If you believe an assessment is inaccurate or outdated, please reach out on X at @centauridoteth. The goal is an objective, community-verifiable risk assessment to help users make informed decisions.