The Curve Exploit

How a blue chip protocol was attacked for $70mm

Smart contracts in the Ethereum ecosystem are written in one of two languages, Solidity or Vyper. When the contract is deployed, it is compiled down to from something a human can understand to something a machine can understand. The compiler code that performs this translation is critically important to making sure that the instructions received by the machine reflect the intentions of the human developer.

One common exploit in DeFi is a reentry attack, which is when a request is sent to a smart contract, interrupted, and then something is allowed to happen that should not have happened.

Here is the best non-technical example I can come up with:
1. You go to a restaurant
2. You order food
3. Food is delivered
4. Your friend points and says, “Hey, what’s that?”
5. The waiter looks
6. You take your side of fries and hide it under the table
7. When the waiter looks around, you say, “Thanks but I’m missing my fries.”
8. The waiter goes and gets you more fries
9. Rinse and repeat steps 3-8 until there are no fries left in the restaurant

You were only supposed to get one order of fries, but you got all of the fries. Reentrancy kind of works like that, but with a smart contract attacking another smart contract to alter it’s intended function by interrupting the flow of logic.

In the restaurant example, these are the players:
- Waiter: The machine code running on the EVM
- Manager: The smart contract developer
- Translator: The compiler

Because the waiter and the manager speak different languages, they rely on a translator to pass instructions. Unfortunately, on the day the new waiter was hired, the translator thought “Verify they did not get fries before you bring them more” in the manager’s language meant something like “If they say they did not get fries, bring them more” in the waiter’s language.

Although the writers of the Curve smart contracts had measures in their Vyper code to prevent the attack, the version of compiler that converted the code to machine code had a bug and did not correctly translate the intention of the developer. This led to a reentry vulnerability for the token pools that were drained.

The exploit would not have been apparent when auditing the Vyper smart contract code, because it was not an issue with the Vyper code. The issue was with the Vyper compiler. This has created a bit of drama in the development community around whether it even make sense to have multiple languages for smart contracts right now. Are the benefits of using new languages worth splitting the developer talent and expanding the attack surfaces? I think there are going to be a lot of Vyper projects reconsidering their choice in language and migrating to the larger Solidity community.

---

Disclaimer

We, Digital Opportunities Group, LLC, are not providing investment or other advice. Nothing that we post on Substack should be construed as personalized investment advice or a recommendation that you buy, sell, or hold any security or other investment or that you pursue any investment style or strategy.

Case studies may be included for informational purposes only and are provided as a general overview of our general investment process. We have compiled our research in good faith and use reasonable efforts to include accurate and up-to-date information. In no event should we be responsible or liable for the correctness of any such research or for any damage or lost opportunities resulting from use of our data.

We are not responsible for the content of any third-party websites and we do not endorse the products, services, or investment recommendations described or offered in third-party social media posts and websites.

Nothing we post on Substack should be construed as, and may not be used in connection with, an offer to sell, or a solicitation of an offer to buy or hold, an interest in any security or investment product.