DeFi: Dependency Hell Meets Finance
Imagine npm bugs for your money. In a sense, that’s what we’re creating with DeFi.
Financial engineering relies heavily on composability, and so does DeFi. This results in an interconnected, intertwined web of primitives. Imagine a SetProtocol Set (a smart contract). It could contain Compound cDAI (another smart contract). cDAI is a claim on DAI (yet another smart contract). To top it off, multi-collateral DAI could be backed by USDC or WBTC, even more smart contracts.
It’s smart contracts all the way down.
If cDAI is frozen, Sets can’t be unbundled. If DAI loses its peg, lenders of other assets in Compound could bear the loss. Everything is affected.
We hear a lot about the magic of composability in DeFi, or “Money Legos.” I want you to remember that it could become “Money House of Cards” in a flash.
This nested risk is called Dependency Risk, which is one of the six risks I cover in this talk at ETHWaterloo2. Other risks include: Smart Contract Risk, Liquidity Risk, Admin Risk, Oracle Risk, and Centralization Risk. I plan to cover these in an upcoming blog post, so now’s a good time for you to subscribe.
Vulnerabilities are inevitable
Exploits are a question of when, not if. This isn’t surprising for an ecosystem as innovative and fast-paced as DeFi, but it’s all the more reason to take risks seriously.
Developers have a finite amount of time to write code, but hackers have an unlimited amount of time to exploit it. In fact, developers are also squeezed by tight deadlines and the fast pace of startups. In a nutshell, it takes developers 3–6 months to ship a protocol, and it takes auditors 3–6 weeks to audit it. Developers make mistakes, auditors miss vulnerabilities, and hackers discover novel exploits. It’s happened before, and it’ll happen again:
Exploits will happen more and more as hackers realize how feasible, lucrative, and unpunished they are. The recent back to back bZx exploits are great examples, given how simple they are at their core. They can be explained in less than 280 characters each:
Not bad for a day’s work.
The hacker(s) will be probably never be punished. They were clever to cover their tracks with anonymity tools like tornado.cash, but it looks like that might’ve been unnecessary:
Many think that exploiting smart contracts should be allowed. (Whether they’d really let a de-anonymized hacker walk is another question, but the point still stands.) You can’t rob a bank and get away scot-free, but you can rob a DeFi bank and get away scot-free. (Remember folks, the c̶u̶s̶t̶o̶m̶e̶r̶ code is always right.)
You (the bank robber) don’t even need to be ultra technical. You don’t need to be well-capitalized either, thanks to flash loans. The bZx oracle exploit could’ve been conceived and executed by any striped-shirt-wearing-tiptoer, without expert Solidity skills.
This reminds me of another vulnerability discovery in Augur, told by Scott Bigelow:
We ran a HackerOne bounty. […] What was interesting is that somebody read the high-level description of how Augur was supposed to work, didn’t even look at the code, and filed a bug bounty.
Another nugget:
This is very well tested code. But we’re testing the wrong thing.
Smart contract bugs are one thing, economic bugs are entirely different.
Mitigating Risk
So, should you park your life savings in DeFi so you can earn 12%? Probably not, but don’t take my financial advice (which isn’t financial advice by the way). For those who are doing it anyway, you can mitigate risk a couple of ways:
- Require contracts to be audited. To go a step further, verify that the audit was done by a reputable firm. To go a step further, read the audit report yourself. To go a step further, remember that dependency risk means you should also do this with every dependency. And every dependency’s dependencies. And every dependency’s dependencies’ dependency. You can see how hard it is to do this properly.
- Use the test of time. The longer a smart contract sits plump and exposed, available for the world to exploit it, the more likely it is that it won’t be exploited. (See the Lindy effect.) Two caveats: first, some hackers might be like the Witch from Hansel and Gretel, waiting for the kids to fatten up before feasting. Second, the Ethereum VM itself may change with a future hard fork, introducing vulnerabilities that didn’t exist before. Just because code is secure today, doesn’t mean it will be tomorrow.
- DeFiScore: For those who don’t have the time to read audits on their own (basically everyone), you can look to those who do. DeFiScore is a place to start. However, note that Fulcrum (bZx) scored as high as 7.1/10 yet was still exploited.
- DeFi insurance. (Or should I say DeFisurance? 😉 @nemild may be accepting bids for defisurance.com 🙂) Talented teams are working on crypto-native approaches to insurance. One I’m excited about is Opyn, which uses put options for cTokens to insure Compound deposits. Of course, these smart contract systems have their own set of risks that need to be mitigated. That said, I’m looking forward to seeing how things play out.
Conclusion
Dependency risk is often overlooked, so I hope you think back to this article the next time you come across a shiny new DeFi product. It’s inevitable that we’ll see more exploits in the future, and I want us to be more prepared for them. I look forward to seeing risk mitigation improve, and seeing DeFi taken to the masses.
But for now I’ll leave you with this: composability is a double-edged sword.
