What happened with the 0x contract exploit?

Breaking down the 0x Exchange v2.0 contract exploit, and why Hydro Protocol is not affected by this type of exploit

On the evening of July 12, 2019, 0x announced that there was a potential exploit in their 0x v2.0 Exchange contract. They immediately shut down their v2.0 Exchange contracts to prevent funds from being lost.

Since the initial Hydro Protocol smart contracts were inspired by 0x, we were subsequently contacted by concerned users and developers wondering if we were susceptible to similar exploits. Fortunately, Hydro Protocol is NOT affected by this type of exploit.

This article summarizes the context of the 0x exploit, why Hydro is not affected, and some lessons learned from the potentially catastrophic exploit.

What exactly was the 0x exploit?

The exploit revolved around a novel signature method introduced in 0x 2.0 called WalletSignature. In theory, this new signature scheme unlocks potentially new exchange use-cases between smart contracts.

The logic was missing a check to see if the account is a normal account or a smart contract. The missing logic combined with peculiarities of the EVM makes it possible to forge valid signatures for arbitrary 0x orders.

A hacker could have used this exploit to forge lopsided orders and drain all approved token allowances from every Ethereum address that had given approval permissions to the 0x v 2.0 contract.

Why is Hydro not affected by this exploit?

Although Hydro Protocol was inspired the 0x architecture, we were very diligent in taking the minimal amount of features necessary to build a first class decentralized exchange.

In our opinion, the WalletSignature module wasn’t useful to relayers in practice, therefore it was not included in the feature set of Hydro Protocol.

Furthermore, although we borrowed some ideas from the 0x repository, we rewrote, tested, and audited every single line of code from scratch.

Lessons Learned

Trust-less forking

0x’s nightmare scenario was prevented because samczsun was kind enough to notify the team in private. Unfortunately, this act of kindness was not carried forward. As soon as 0x patched the issue, they made the knowledge public. Although this was probably a case of oversight rather than malice, the result could have been catastrophic if anyone had carelessly forked over the code that contained the vulnerability.

At the end of the day, it is our sole responsibility to take full ownership and responsibility of every line of code we deploy.

Viability of Proxy Contracts

Smart contracts are immutable, meaning once they are deployed they cannot be changed.

The proxy pattern is an attempt to circumvent this “limitation”. The idea is that if you make users interact with the core logic(exchange) through a proxy, the exchange can be upgraded without the user having to know. Furthermore, the proxy pattern allows contracts to retain on-chain state during upgrades.

However, in the scramble to patch 0x 2.1, a completely new proxy was deployed, forcing all 0x relayers to upgrade and discard all on-chain state.

In contrast, most other DeFi projects don’t use such a proxy. For example, when Compound released their 2.0 upgrade, they simply deployed brand new contracts and asked users to manually migrate.

Moving forward, Hydro Protocol will reevaluate the worth of asset proxies. More to come on this.

Even Top Engineers and Auditors are Only Human

The 0x contract was audited by multiple professional teams of the highest caliber. Prior to creating Hydro Protocol, we spent time and money for both internal and external audits of key portions of the 0x code-base. In the end, everyone missed it.

The postmortems on the web are mostly focused on the specific technicalities of the exploit: solidity assembly, signature schemes, and external contact calls. These are important lessons to carry forward. But the biggest lesson for us is that everyone is fallible. The best way to minimize mistakes is to ruthlessly cutaway frivolous features and keep things simple.

Thanks for reading!

Hope this helped shine some light on this exploit, and provides some lessons for upcoming decentralized products. Let us know if you have any questions or feedback, we’d love to hear from you.