Code bugs, hackers, market volatility, arbitrageurs: the DeFi risk management paradigm

DeFi refers to decentralized financial protocols implemented with smart contracts, including asset trading, lending, insurance, various derivatives, etc. With the exception of credit services, realistic financial services can be implemented through DeFi protocols. These protocols are decentralized and automated, with no third-party institutions managing and maintaining them, so the risk control of the contracts becomes an industry challenge.

DeFi has both financial and technological attributes and contains the following risks:

• Code risk. Including the risk of the underlying code of Ethereum, the risk of smart contract code, the risk of wallet code, etc. For example, the famous DAO incident, the Uniswap vulnerability attack problem, and various wallet theft incidents are all caused by code risk.

• Arbitrageurs risk. Mainly the business design process is left with loopholes, being reasonably attacked or manipulated. For example, the FOMO3D was blocked attack, dZx wrongly used the Uniswap oracle machine which is not resistant to attack, and was reasonably suppressed price to steal assets. This type of person is called an arbitrageur. Arbitrageurs have both disadvantageous and advantageous sides to a DeFi project.

• Market volatility risk. DeFi is designed to lack some counter variables, leading to market extremes that occur in the event of a position penetration. For example, MakerDAO has experienced the risk of extreme market volatility.

• Oracle risk. The oracle machine provides global variables and is the basis for most DeFi. If the oracle machine suffers an attack or a stoppage, the downstream DeFi will fall into collapse. We believe that oracle machines will become the most important infrastructure for future DeFi, and oracle machines with any centralization risk will eventually go extinct.

• Technology risk. This refers to the risk of ordinary users who are unfamiliar with smart contracts and blockchain using a "convenience" interaction tool developed by a centralized team.

Any DeFi project should be designed in mind with the risks of code vulnerabilities, hackers, market volatility, arbitrageurs, etc. A complete process is not just about good tips in the documentation, but also about risk management tools. Most of these tools are done in a decentralized way, and a few are done in a community governance way (mainly referring to on-chain governance). Here we propose a DeFi risk management framework, mainly divided into ex ante, halfway and ex post.

• Ex ante: The main focus is on formal verification of the contract code. It includes figuring out the boundaries of methods, resources, and even instructions used by the contract, and the impact of the relevance of these methods, instructions, and resources in the combination process. This is not traditional software development testing thinking; this is a concept close to mathematical argumentation. Good contract development should be based on a combination of methods that have been validated.

• Halfway: Halfway mainly focus on the downtime design and exception trigger design. That is, the contract is able to identify and intervene in attacks, including automatic downtime design and governance downtime design. The anomaly trigger is a kind of control management of the contract operation process, exceeding the expected phenomenon. Exception triggering is generally automatic, and some risk management variables are corrected by exception triggering. See the beta factor and anti-blocking attack settings in the NEST Oracle Machine system, which is one of the industry's pioneering practices considering downtime and abnormal triggering.

• Ex post: Ex post risk management has several components. The first is a vulnerability in the code that needs to be fixed, typically through on-chain governance, i.e., DAO governance. The second is an attack on the governance asset itself, at which point a contract fork is required! This is a blind spot that the industry has overlooked. The next is to reduce losses by insuring the contract against possible risks through an insurance mechanism. Finally, the community can work with various institutions to track losses through the tracking of on-chain data. For on-chain governance and contract forking, see the design of NEST, which is an innovation.

The current understanding of security in the industry is too early and too traditional. If we cannot change our thinking to introduce new ideas such as boundaries, completeness, consistency, formal verification, downtime, exception triggering, governance, and forking, we cannot adapt to future development.