Auditing the 0x Protocol v2 with ConsenSys Diligence

Gerhard Wagner
ConsenSys Media
Published in
3 min readSep 12, 2018

ConsenSys Diligence is a ConsenSys service providing audits of smart contracts and programs built off the Ethereum network. Periodically, ConsenSys Diligence will publish a summary of an audit, including weaknesses and recommendations for clients. Recently, the Diligence team completed an audit for the 0x protocol v2 upgrade. Read a recap of the team’s conclusions below.

Scope

The in-scope items can be divided into the following three distinct parts:

  • Exchange: contains the bulk of the business logic within the 0x protocol. It is the entry point for filling orders, canceling orders, executing transactions, validating signatures and registering new ERC Proxy contracts into the system.
  • Asset Proxy is responsible for decoding asset-specific metadata contained within an order, performing the actual asset transfer and authorizing/unauthorizing Exchange contract addresses from calling the transfer methods.
  • Forwarder enables users to buy assets (ERC20 or ERC721 tokens) with ETH. It removes the required knowledge of WETH and allowances.

Issue Overview

25 issues were identified during the audit. About half of the issues have been prioritised and already fixed during the initial audit phase. Remediation efforts to fix the remaining issues are currently ongoing. The full list of issues can be found in the issue table overview.

Closed and Open Issues per Severity

Recommendations

We found the quality of the code base to be high, which is especially appreciated when approaching a complex protocol. In particular:

  • The specification documents are thorough and well written. The diagrams of the system’s interactions help to visualize the system.
  • The code is well commented, particularly in sections where understanding the developer’s intent is essential.
  • The organization of the contract repository is thoughtful and consistent. For example, the names of Solidity contracts which are inherited but not deployed are differentiated with the prefix Mixin_. Interfaces are prefixed with M_.

Relative to the v1 version of the system, the v2 updates introduce features that significantly improve the user experience. They also introduce many new edge cases, which directly resulted in two critical issues, that have been already fixed during the initial audit phase. These features include:

  • Support for multiple SignatureType values especially Caller, which was unique in that it did not check the signature. It rather assumed that if msg.sender is equal to order.makerAddress then the order is valid and was in fact created by the msg.sender. See section 3.2 for more information on the resulting issue.
  • Enabling a 3rd party to call Exchange functions on behalf of a user. See section 3.1 for the resulting issue, and remediations.

We believe that the system lacks a rigorous and systematic testing strategy that ensures comprehensive test coverage beyond mere line/branch coverage. We found that many important behaviors were untested during a spot check of the test suite. For more detailed information see issues 3.4, 3.7, 3.10, 3.11 and 3.14.

Report

The complete report for the audit has been published here. Github issues were created in a separate audit working repository and links contained in the report are only accessible to the 0x team and the ConsenSys Diligence audit team.

I’m part of the team at ConsenSys Diligence. If you have a knack for diving deeply into Solidity and the EVM, and an interest in smart contract security, we’re looking for people to join our team (Apply here).

Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.

--

--