DeFi: Dependency Hell Meets Finance

Daniel Que
5 min readMar 3, 2020


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.

DeFi depicted as a house of cards.

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:

Some notable vulnerabilities and exploits: bZx 2, bZx 1, Compound V1, 0x v2.0, Bancor, Parity Self-Destruct, Parity Multisig, The DAO.

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, but it looks like that might’ve been unnecessary:

If code is law, then it’s within the law.

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.

It might not look like it, but this bandit has millions in good money stashed in that little bag.

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 🙂) 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.


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.

Dependency risk is the yin to composability.

Thank you for reading! I like Tweeting @dmdque. Sign up here to be notified of future posts. Thanks to Nemil Dalal (@nemild), Regina Cai (@lildex), Jing Wang, Tyson Batistella, Stani Kulechov, and Hart Lambur for the feedback on this article!



Daniel Que

Engineer @ Coinbase. Previously Co-Founder of CryptoFin (aq by Coinbase), Engineer @ Uber.