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 expected performance of the system (but user funds remain unaffected) | Possible upgrades do not materially change the expected performance of the system (or result in the theft or loss of user funds and unclaimed yield) |
| Autonomy | Dependencies may cause theft or loss of user funds and exhibit Stage 0, or equivalent, centralization | Dependencies may cause theft or loss of unclaimed yield, or may otherwise materially change the expected protocol performance, OR dependencies exhibit Stage 1, or equivalent, decentralization | Dependencies (if any) cannot materially change the expected protocol performance, OR dependencies exhibit Stage 2, or equivalent, decentralization |
| Exit Window | Upgradeability score is 'High' AND permissions are protected with an exit window of less than 7 days (or no Exit Window) | 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 onchain governance process 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. |
|
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-insider signers
- Signers are publicly announced (with name or pseudonym)
Note that we refer to an "insider" as any party of the "inner circle" of individuals or entities developing, maintaining and operating the protocol, such as the "team members" or a company mandated to perform certain services.
These requirements translate to a set of at least 7 signers, identified through their name or pseudonym, and a threshold qualified by a majority of signers including at least one "outsider".
Others Protocol Category
The stages framework considers a set of basic requirements to enter Stage 0 and qualify as a DeFi protocol. The Others protocol category captures protocols which are built using blockchain technology and serve a financial use case but do not meet one or more of the Stage 0 requirements:
- ✅ Blockchain-based, financial protocol
- ❌ Assets are not in custody by a centralized entity
- ❌ Public documentation exists that outlines the protocol components and expected performance
- ❌ Source-available codebase
- ❌ Verified contracts
The Others protocol category thus shines a light on protocols which either fail to disclose the required information publicly, such as documentation (aka a Whitepaper) or software source-code, or do not meet basic requirements to qualify as a DeFi protocol.