Process Quality Reviews v0.8 Release: Timelocks, Oracles, and Expansion

DeFiSafety is proud to announce the release of the newest iteration of our reviewing process: v0.8! We are implementing new metrics within our reviews. These new implementations aim to reflect our answers to two questions we ask ourselves before every reiteration of our process:

• “What are the current process quality flaws in the blockchain space?”
• “How can we help bridge those gaps?”

Our solution lies in incentivizing developers to:

1) Build a more rigorous development process

2) Incorporate transparency and traceability for their users’ sake

Establishing a trusting relationship with its users is paramount to any protocol’s success. This can be accomplished by being transparent and rigorous.

However, the more vulnerabilities arise in Web3, the more data needs to be provided. This is why our methodology is centered around filtering through which current vulnerabilities are prominently exploited, and the analysis of what key information is currently missing from the protocol developers’ technical documentation.

v0.7 Recap

When we created v0.7, we added Admin Controls. We realized that developers weren’t adequately documenting the full extent of their control over a protocol. Users were not aware if the smart contracts they interacted with were immutable, upgradeable, or prone to sudden changes at the developers’ discretion.

The Poly Network hack is a perfect example of admin control mismanagement: had they documented their contracts’ ownership clearly both internally and externally, it would have potentially identified the possibility of an exploit within the ownership parameters of the EthCrossChainManager contract. As such, implementing ownership documentation is important for both transparency and verification purposes.

For instance, we have worked with Balancer, Maple Finance, Loopring, Shapeshift, and Alpaca Finance to broaden their documentation to include this vital information. Their teams recognized the importance of taking the necessary steps, and have helped us set a good example for the rest of the DeFi protocols.

Now that we’re all caught up, let’s get down to the juicy stuff.

v0.8 Breakdown

Before we go down the rabbit hole, let me give you a general overview of our changes to our process.

• A complete overhaul of our Process Documentation which you can find here. This document breaks down our methodology for each question in our Process Quality Reviews
• Redistribution of our question’s scoring weights across the board
• An expansion of “Admin Controls” section with new questions pertaining to timelocks
• The addition of a new section: Oracles

For a shorter, technical breakdown of everything that’s been added, here is our v0.8 change log.

Major Expansion of our Process Documentation

One of the biggest changes that we are introducing with 0.8 is a rejuvenation of our Process Documentation. In total, we have approximately tripled the contents of it (4,963 to 12,931 words), and have made it as readable as possible while also providing a sufficient amount of technical detail. We have included more information regarding our scoring methodology and philosophies which give a deeper insight on how we analyze the process quality of the hundreds of protocols that we have reviewed so far.

The primary goal of this documentation is educating our users about the importance of rigorous development and documentation standards. Nonetheless, this document is as much a guide for users as it is for developers. Users should know what to look for in a protocol that indicates a good development standard, and developers should know what parts of their process is lacking or insufficient. This is why we chose to provide a more detailed framework on how a team can improve their scores for each question in their respective “Scoring” and “How to improve this score” sections.

I understand that it can be quite a daunting and laborious read, but I promise that any answers you seek about our process are in this documentation. We hope that users and developers alike can use it to learn about us and what the ideal development process should looks like.

Redistribution of Scoring Weights

In our process, there are questions and sections that weigh more than others.

With the addition of the “Oracles” section, the individual weights of other sections reduced to make up for the overall increase of possible points. The only section that avoids these reductions is “Admin Controls”, primarily due to the addition of timelock-related questions, but also due to us deciding that we should allocate more possible points for this section overall. The new rankings for our sections in terms of percentage weight are: Security (23.4%), Admin Controls (23.4%), Testing (15.6%), Smart Contracts and Team (14.1%), Oracles (12.5%), and Code Documentation (10.9%).

All these weight redistributions are due to weight changes to most of our individual questions. You can view all of them in our change log.

Expansion of our “Admin” Controls Section and Addition of Timelocks

In v0.8, we further expand this section. This is due to the perpetual lack of Access Controls transparency that is still present in DeFi today. Hence, we have decided to increase the contents of the section by separating Question #20 into three distinct questions. Question #20 used to be:

20) Is the information clear and complete

• All the contracts are immutable — 100% OR
• All contracts are clearly labelled as upgradeable (or not) — 30% AND
• The type of ownership is clearly indicated (OnlyOwner / MultiSig / Defined Roles) — 30% AND
• The capabilities for change in the contracts are described — 30%

For 0.8, we have decided to split this question into three questions that go over each of these components individually and in greater detail. This allows for more technical information, and more accurate scores. A more technical description of these questions can be found in our Process Documentation. The split of Question #20 goes like this:

19) Are relevant contracts clearly labelled as upgradeable or immutable?

This question evaluates which protocol’s smart contracts are identified as being upgradeable or immutable within their documentation. Immutable code is a staple of blockchain technology and having code that cannot be changed post-deployment is fundamental for ensuring that the team cannot exploit its own software. For contracts that are not immutable, it is still important to label them as upgradeable to maximize transparency.

20) Is the type of contract ownership clearly indicated?

This question evaluates the ownership parameters of a protocol’s smart contracts. Such parameters can include: OnlyOwner, MultiSig addresses, or Defined Roles within governance. A protocol defining the ownership of its contracts is arguably one of the most important aspects of user transparency. Community members deserve to know who has access to the backend, and who has the power to implement changes.

21) Is the contract change capability described?

• This question evaluates the identification of which parameters can be upgraded within a smart contract. If traceable ownership parameters are the most important aspect of Access Controls, then the traceability of change capabilities within a smart contracts’ code is a close second. Users should know which smart contracts are subject to change, especially within a governance structure. A protocol’s team not fully disclosing this information can be suspected of having the potential to implement changes at their own discretion at any time, which is really not ideal for users’ fund safety.

In addition, we have added questions pertaining to timelocks to our Admin Controls section. Timelocks are an important layer of security that all protocols implement within their core smart contracts. They serve as a way to delay any upgrades or calls that a protocol’s team might want to perform on one of their contracts. Although this is a fundamental aspect of governance protocols, it is becoming increasingly vital for non-governance protocols to utilize timelock contracts in order to mitigate the chances of sudden rug pulls. If a protocol wanted to rug pull a contract that is protected by a timelock, the transaction would be first be added to a public transaction queue for a certain amount of time. This would allow anyone to spot this transaction, and plan accordingly.

As a result, timelocks removes a degree of administrative power from the protocol’s team since they are inherently held more accountable through the traceability of their actions (see OpenZeppelin’s article regarding timelocks).

The new timelock questions are:

24) Is there sufficient Timelock documentation?

• Since Timelock contracts have a high degree of importance when it comes to user transparency, they should also be adequately documented. There are three main metrics that we keep an eye out for in a protocol’s documentation: the existence of a Timelock contract, the smart contracts in which the Timelocks are implemented, and the specified duration of the lock period.

25) Is the Timelock of an adequate length?

• A Timelock contract’s lock period needs an adequate duration in order for it to be effective. As an example, a lock duration of 5 minutes would be useless as it does not allow enough time for community members to verify the pending transactions. Thus, we have deemed that a Timelock’s locking period should be anywhere between 48 hours to a week in order to maximize its transparency and efficiency. Although this may seem like an arbitrary margin, a 48h minimum is usually enough time to allow for community members to move their assets around if they so choose, and it also enables a good amount of time for exploit verification.

To learn more about our new Timelock questions and its more technical aspects, please go look at our Process Documentation.

Added “Oracles” Section:

With the popularization of Oracles and flash loan exploits in 2020 (see Messari’s Oracle exploit list), the need for proper and diverse Oracle implementation is apparent in 2022. However, protocols lacks a standard technical description of the Oracle source(s) used. Some larger protocols offer this information, but they are a minority. This is an issue, since a user investing into a protocol should be aware of the reliability of its Oracle(s). Of course, we have no way of evaluating the quality of a protocol’s Oracle without having adequate details first. With that in mind, these are the questions we have added for increased Oracle usage transparency:

26) Is the protocol’s Oracle sufficiently documented?

• For this question, we look for four different metrics in a protocol’s documentation: Oracle source(s), a list of smart contracts that incorporate the Oracle(s), basic software functions of the Oracle(s) used, and Oracle(s) price feed refresh rate.

27) Is front running mitigated by this protocol?

• For this question, we look for the steps a protocol has taken to mitigate the possibility of front running within its orderbooks or mempools. A great way of preventing such an exploit is to rely on multiple Oracle sources, such as Chainlink’s decentralized Oracles and Uniswap v3’s TWAPs, in order to increase the price feeds that would have to be front run by an attacker (see Angle Protocol’s front running mitigation strategy).

28) Can flashloan attacks be applied to the protocol, and if so, are those flashloan attack risks mitigated?

• Modern flash loan exploits are used to acquire a substantial amount of liquidity to affect the price of a certain LP/asset. Oracles tend to be a main target in these attacks, as an attacker is essentially trying to trick the Oracles into reporting a false price, enabling said attacker to withdraw assets at an artificially inflated price. Possible solutions include using multiple Oracle sources in order to have a “back-up” price feed option, as well as reducing the possibility of external calls within smart contracts (see Unified Guru’s article about flash loan prevention).

To learn more about our new “Oracles” section and its more technical aspects, please go look at our Process Documentation.

From all of us at DeFiSafety, thank you for supporting us and making these updates possible. We hope that you enjoy using it just as much as we enjoyed making it for you. ❤

Website: https://www.defisafety.com/

Telegram: https://t.me/+zDUuW0wMxak4NjRh

Discord: https://discord.gg/GWA74DnxVB

Knowledge Hub: https://www.defisafety.com/hub