Two serious issues were uncovered shortly after the launch of the Ethereum Name Service (ENS) on March 14th, 2017.

As a community contributor to the project, and a student of smart contract security, this is a bittersweet opportunity to learn from what feels like a punch in the gut. This post is my effort at extracting useful lessons from these unfortunate events. Most of them are operational, and relating to human factors rather than the code itself.

It would be easy for spectators to label this as another “TheDAO”, and ask why nothing has been learned since last summer. But this is a very different situation; the outcome is vastly less catastrophic precisely because of the lessons of the TheDAO, and so we have a new set of lessons worth looking at.

I know that Nick will have his own retrospective soon (update: here it is) , and possibly others, so take this as just one perspective.

The bug(s)

Context: Each name registered with the service has an auction period (during which blind bids should be submitted) followed by a reveal period ( during which the contents of a bid should be revealed).



Bug #1: Nothing prevents a bid from being submitted during the reveal period, so anyone could see the winning bid, and then outbid it, or underbid it by only a small amount in order to force the winning bidder to pay a much higher price. Nick Johnson’s post does a good job of summarizing the issue, and you can take a look at the proposed fix.



Issue 2: A bid value could be “faked”, meaning you could indicate a high bid value, without actually submitting that value. It breaks the bidding process completely, allowing anyone to win any name while only paying 0.01 ETH.

The silver lining (what was done well)

With two significant bugs less than 24 hours in, it looks pretty bad… it’s definitely not good. Fortunately, there were fail safes which will minimize the damage.

Most importantly, the contract can be upgraded to an improved registrar by a committee of key holders, which will prevent the loss of any funds already held by the Registrar. One lesson of “TheDAO” (April-June 2016) was that some degree of central control should be maintained over smart contracts, especially in the early years of nascent Ethereum technology development. The bidding UI had not yet been activated, in order to perform further testing. This protected non-technical users and minimized the amount of money put in.

What was not done well

1. Test coverage was incomplete

Both of the issues uncovered could have been caught with tests to verify proper behaviour of the registrar. The behaviours which the issues enabled were not edge cases, but rather specifically prohibited.



Unrelated, and inactive code was stored in the same repo as the code which was ultimately deployed. This meant that npm test would run 39 tests, but only 13 of those tests were on the Registrar contract, which has at least as many methods and many more requirements than that.

2. There was no “official” bug bounty

A good bug bounty has a significant marketing component, and real value up for grabs. Unfortunately, this is hard to do on a test net, where the tokens have no value, and stuff is expected not to work.



WeiFund’s live net bug bounty, which held over 200,000 USD worth of real value in deployed contract, is a good counter-example. Blockchains present an interesting opportunity for a “natural bug bounty”, we as contract developers should be taking advantage of this.

3. There was no Formal Audit

The review period consisted of several months on Ropsten, and an informal review consisting mostly of a few foundation members, and a few community members. For the most part we were playing around with the code and building a dapp on it.



There is unfortunately no single document summarizing what review was done, and what was found.

4. Thrashing

It’s nearly impossible to audit an evolving code base.

Many changes were made between the Ropsten launch, and the live net launch.