What is DeFiScan?
The maturity of DeFi technology progresses through several stages characterized by different degrees of decentralization. Upon deployment, DeFi protocols often expose critical risks from central dependencies and permissions controlled by centralized operators. As the protocol matures, these risks are eliminated e.g. through the introduction of fallback mechanisms, Security Councils and exit windows. To date, however, these stages have not been formalized resulting in a lack of transparency around the maturity and related risks of DeFi protocols.
DeFiScan offers a framework formalizing the decentralization stages of DeFi technology and allowing, for the first time, to assess and monitor the technology's maturity in a verifiable manner. This framework consists of two parts:
- A centralization risk scoring system based on a scale of "High", "Medium" and "Low" severity risks
- A formalization of the decentralization stages which relates directly to the risk scores achieved by a DeFi protocol
What is DeFiScan NOT?
DeFiScan strictly focuses on the analysis and monitoring of the decentralization stage of DeFi protocols. It does NOT assess or make any statement about other aspects like:
- Smart contract risks
- Regulatory/compliance risks
- UX
- Financial performance
- Any other risk associated with DeFi protocols
Here we provide an overview of the framework. For a more detailed discussion, please refer to the introduction blog post.
DeFi Centralization Risks
| Risk / Scores | High | Medium | Low |
| Chain | L2Beat Stage 0 | L2Beat Stage 1 | Ethereum mainnet or a comparable L1, or L2Beat Stage 2 |
| Upgradeability | Possible upgrades may result in the theft or loss of user funds | Possible upgrades may result in the theft or loss of unclaimed yield or may otherwise materially change the system (but user funds remain unaffected) | Possible upgrades do not materially change the system (or result in the theft or loss of user funds and unclaimed yield) |
| Autonomy | Failure of a dependency may result in the theft or loss of user funds | Failure of a dependency may result in the theft or loss of unclaimed yield or may otherwise materially change the performance of the system (but user funds remain unaffected) | Failure of a dependency does not materially change the performance of the system (or result in the theft or loss of user funds and unclaimed yield) |
| Exit Window | Upgradeability score is 'High' AND permissions are NOT protected with an exit window or the exit window is less than 7 days | Upgradeability score is 'Medium' OR permissions are protected with an exit window of at least 7 days | Upgradeability score is 'Low' OR permissions are transferred to an on-chain governance process AND protected with an exit window of at least 30 days |
| Accessibility | A single user interface exists without a backup solution resulting in the temporary freezing of user funds if the interface is shutdown | A single user interface exists with public access to a backup solution such as a self-hosting app | Multiple independent user interfaces exist, e.g. websites, in-wallet access, etc., guaranteeing access to user funds even if one interface is shutdown |
DeFi Stages Framework
| Stage | Description | Qualification |
| Stage 0 | This is the first stage of a DeFi protocol where basic requirements give the technology a decentralized foundation. Critical permissions are still controlled by centralized operators and external dependencies may expose critical risks to users. Yet, its foundation allows for the gradual decentralization and elimination of these risks. |
|
| Stage 1 | In the second stage, risks from critical permissions and dependencies are significantly reduced by either revoking critical permissions, or establishing a Security Council to control such permissions, or enforcing an exit window of at least 7 days so users can withdraw funds in case of an unwanted protocol update. Critical risks from external dependencies are mitigated by the implementation of appropriate fallback mechanisms. Furthermore, the underlying chain cannot censor users' transactions and a backup user interface exists guaranteeing access to user funds. |
|
| Stage 2 | The final stage is reached when critical permissions have either been revoked or delegated to an on-chain governance system with ample time for users to exit in case of an unwanted protocol update. Risks from external dependencies have been further reduced such that users' funds and unclaimed yield remain unaffected by a failure. In addition, different independent user interfaces and a fully decentralized underlying chain guarantee access to users' funds at any time. |
|
| Review | The review of a protocol cannot be completed due to missing information or a change in conditions. As a result, the analysis is incomplete or inaccurate and the Stage unclear. |
|
Security Council Requirements
A Security Council can represent an effective intermediate step of decentralized control over permissions that cannot be revoked or protected with an Exit Window. In particular, a Security Council enables a protocol to mitigate risks of centralized control over such permissions and enter Stage 1.
Any multisig account with the following minimal requirements is an acceptable Security Council setup:
- At least 7 signers
- At least 51% threshold
- At least 50% non-team signers
- Signers are publicly announced (with name or pseudonym)