Ken Deeter, a partner at crypto venture firm, Electric Capital, proposed a pragmatic approach to ensure decentralized finance, or DeFi, projects are not exploited due to bugs in the system.
In an article published on May 27 through the Electric Capital blog, Deeter calls for DeFi projects to introduce “better risk management.” This largely comes as a response to the many hacks and protocol failures that occurred in recent months, like the temporary theft of $25 million from the dForce protocol.
Deeter believes that DeFi should adopt some of the established techniques in the tech industry, which makes heavy use of “canary deployment” — the practice of gradually rolling out new features to portions of the user base. He conceded that this approach cannot be directly applied to blockchain, but the principle holds:
“The core underlying idea remains applicable: start small in a low stakes environment and then increase exposure and risk in a controlled manner.”
Guarded launches
Deeter proposed a gradual launch process for DeFi projects, using rules and thresholds that limit the functionality of the system. As the developers gain confidence in the reliability of the system, governance processes can be used to relax the restrictions.
The restrictions can be of a varied nature, and include hard limits on the capacity of the system in terms of asset amounts, types and number of users. Restricting composability is also an important part of this concept, as several of the previous hacks were eased by complex interactions between different protocols.
Finally, traditional risk management like escrow, insurance ratio and conservative loan-to-value ratios can also be helpful. Emergency shutdown capability was also cited.
Deeter noted that several DeFi projects, like Maker, Compound, and Uniswap, already include some of these mechanisms.
Deeter argued for the creation of standardized smart contract libraries and services as part of a “DeRisking as a Service” concept. These would create a plug and play option for projects to implement these controls. Deeter compared this approach to OpenSSL and gnutls, which already perform a similar function in some crypto projects, he argued.
Generic libraries could be thoroughly tested and audited and thus make smart contract deployment safer.
Freedom or pragmatism?
The DeFi community remains fractured in deciding if additional security at launch is worth the compromise of restricting freedom of use. A poll run by Defi Prime asking if DApps should be limited to a $100 maximum transaction size saw the “no limit” camp win by a small margin.
Deeter told Cointelegraph that “we have had very positive feedback to the idea of Guarded Launches.” He noted that some projects see more liquidity “than they are comfortable within a short time,” and a progressively decentralizing launch is a “better fit for different types of projects.”
Commenting on the launch of tBTC, which has often been praised for quick and decisive action to prevent losses, he said:
“The transaction size restriction that was included in the tBTC web UI is definitely an example of a technique that we would consider as part of the Guarded Launch approach. I'm sure it had some effect at limiting the consequences of the eventual problem that was discovered.”
Toeing the line between decentralization and pragmatism can be a difficult task, as MakerDAO’s co-founder, Rune Christensen, told Cointelegraph.