ENS, the Ethereum Name service, provides a simple service. It maintains a directory that maps names like somename.eth to Ethereum addresses. There are procedures for registering new names, transferring names, renewing registrations and such. It is something like DNS is for the internet. And now there is a big fight over the contents of the ENS DAO treasury.
It is a fascinating story because it involves a few uncommon characteristics for web3. The product works. It is used. It generates, or at least generated, a lot of real revenue. And while it has a governance mechanism, it has achieved all it has achieved with remarkably little ongoing governance or development. In a basic sense, ENS is a massive success.
But of course a simple, working, revenue generating product controlled by a discrete group of people is not very web3. Further, this product ended up generating a lot of revenue with not too much by way of expenses. And it did so without any massive ongoing structural evolution or complex governance debates. It is a relatively simple product that basically worked and works. A lot of machinery was set up to handle upgrades and protect the protocol and so on. But in the end little was done and a large pile of cash will revert – as it has been programmed to do for a long time – to the founding team. Many people are unhappy about this. We, for the most part, blame those people for doing nothing about it and ignoring this obvious incoming outcome for a long time.
This entire story is about a group of people operating within a system they all understand and with incentives everyone knows about. They may pretend it is all about the legal system – and sometimes they might even make a few gestures in that general direction. But really it is a story about people playing games that is as old as the ideas of finance and technology themselves.
Is ENS Useful?
Yes. ENS absolutely is not useless. But it is also not fair to compare its usefulness directly to DNS which was the original inspiration for ENS. Both schemes allow users to use human-readable sequences of letters rather than long meaningless character strings. But there are other solutions beyond name registries for this problem. Back before good search engines with broad coverage existed – the entire 1990s and some of the 2000s – you really needed to know the name or numerical address of a site you wanted to see. You could not just reliably "google" the name and get the answer back. Why? Well Google did not exist yet. And in general search engines were not great. Even in the early days of Google, things were not as they are now.
There was, however, an alternative. Yahoo was not originally a search engine – it was a directory. Sites were organized into categories and you could browse by topic and region and similar categorizations. You could "search" within Yahoo's categories. But that bore little to no resemblance to a modern search engine. Human readable and usable, site names were essential because the search engines and directory services that existed had limited partial coverage. They were far closer to library card catalogs than modern search tools. And early search tools would often return 10s or 100s of thousands of results that looked to be sorted randomly. Life was tough. Everyone that used AltaVista remembers this. AltaVista had a sophisticated programming language that put the burden on users to filter millions of possible hits.
Google replaced that entire style of scheme. If you are looking for just about any website now you can just put the name into a modern search engine and the site pops out. When is the last time you carefully typed in a site address rather than just searching for it? Oftentimes you can just describe what you want and a modern search engine finds it. Could you live without DNS now? For web browsing probably. Email would be a problem without DNS. But it is pretty clear the search engine providers would just support email domains and that problem would mostly get fixed too. You cannot really google an email address today. But it is obvious Google could build that kind of thing if it wanted or needed to. Google runs a massive free email system. Adding search for addresses would not be hard.
And what about ENS? Block explorers perform much of the search function for web3. So do various intelligence platforms. Many of them have limited free offerings. And without ENS it is reasonable to assume we would find ad-supported search-like platforms, ala google, that did an adequate job. And do not forget that web3 projects almost universally host documentation – which, recall, you can already find with a search engine – that lists all their addresses and provides links. A search engine provider could build a tool to cover for the lack of ENS as well. This, too, is easy.
For other people's personal addresses this could be a little messier. And the analogous problem is how to find not company emails but free personal ones. Is gmail supposed to provide a free directory search? Do you think that would be useful? Of course not. Coverage remains patchwork and ENS is filling a gap.
ENS' job is actually simpler than DNS' for another reason: blockchain addresses are generally fixed. The IP address of servers for services on the internet – the things DNS is mapping – change frequently. But the Ethereum addresses underlying ENS are fixed. Once a contract is deployed it does not move. ENS has an easier job than DNS but there is still a gap to be filled by some solution, DNS-like or otherwise.
So there is utility here. But it is limited. And the use cases largely overlap with simple, solved engineering problems where we already know how to fund free public tools (with ads like google). If etherscan had launched an ad-supported ethersearch before ENS came around maybe ENS would never have made it.
Does ENS Really Need A DAO?
If ENS fills a useful but limited niche the next question is: does it need governance at all? And if so what form of governance does it need? The mechanics of name registration and lookup are all well settled (ref: DNS). Having some bug-fixing mutability for a while to iron out the software may be reasonable. But you do not need a lot of power to do that. You do not need a token either – there is no reason this cannot be managed by the developers with a multisig that eventually dies out.
But how do you set the price for new registrations and renewals? Anyone that has registered a DNS name knows pricing can be all over the place. The fairest, most "decentralized" way is probably to run some sort of auction. But what auction type? Where does the revenue go? There will be money from sold names and probably different ideas about the best mechanisms to use for pricing everything.
On this front there is a plausible case for a token and a DAO. Paying revenue out periodically to tokenholders is certainly reasonable. Here we will just ignore the question of whether this makes the whole thing a security and whether that would have mattered at launch or matters now. At a high level a token that gets the revenues is reasonable. The alternative – passing the revenue to a company that owns the whole thing – is just going to lead to a DNS-like situation where various companies compete to sell various groups of names and it is a mess. The point was to build something better right?
And alongside the revenue question there is a plausible case to propose and vote on new auction mechanisms for initial registrations and renewals. As many variants of the same name are likely equally acceptable for most buyers it is genuinely unclear what the "best" approach is here for these steps. It is not even clear what "best" means. Is it "raises the most revenue?" or "gives the largest number of people names they are happy with?" or "sells the most names?" or something else. This is a reasonable DAO use case in theory.
The Security Council
ENS went with an interesting hybrid approach to punting on all of these questions. A token exists which gates DAO voting. And the DAO is further protected from bad proposals through a Security Council which can veto DAO proposals. This is fairly normal. The DAO, so long as the Security Council does get in the way, can rearrange the mechanics of ENS pretty much as it likes. This too is fairly normal.
The interesting wrinkle is that the Security Council has a fixed expiry date. The DAO gave itself until this time to resolve at least the most basic governance questions and get something permanent in place. This thing has been around for years now. And yet here we are up against the expiry date and +/- nothing has been done about governance. And ENS has not explored much of the design space either. The default outcome is for the Security Council to go away. The issue, of course, is that a lot of DAO token voting power is concentrated within a small group. So the D and the A will completely disappear from the Organization without a Security Council.
How We Got Here
In practice none of the powers to innovate or protect the protocol mattered. The history of the ENS DAO is not one of nuanced debate over mechanism design and project goals. It works how it worked and has not changed much. And the treasury has accrued a lot of money from selling name registrations.
Sitting here up against the expiry date there are a few stark choices. Obviously the best thing for the protocol as a decentralized and interesting thing would be to give up the Security Council veto and continue exploring the design space via open permissionless processes. This can only be interesting if voting power is diffuse. But none of that has happened to date; why should we expect it to start up once the safety equipment is removed? That makes no sense. The concentrated token holdings are also a fact about the present world. Wondering how things might be different if they were not so is, quite literally, fanciful.
The Security Council expiry was set up so it would expire unless the DAO managed to get an upgrade past that same council to reform the process. This thing was always on autopilot to expiry. And given the low level of activity in the DAO overall it is unsurprising the initial setup remains today.
As with many DAOs an awful lot of the voting control lies with the founding team. Look at the situation from their perspective. However we got here it is true that there was little interest in tinkering with ENS's mechanisms. And even if you want to argue there was interest, there was not sufficient interest backed by funding to buy up ENS tokens and agitate for change. How do we know? Because there was no such change. The record confirms this view is correct.
So now the founders see a large treasury and one mechanism that expires soon sitting between them and controlling all the money directly. Yes they could support and enact a scheme to keep the security council around. They could sell off tokens to give up voting control. They could do a lot of things. But the default destination, the spot programmed into ENS's satnav for years now, is dissolving the Security Council and whoever has voting control owning the treasury.
You cannot very well believe in the importance of incentives in designing protocols and complain this is unfair. It is exactly what you should expect when the safety mechanism expires, the protocol attracts a lot of use but little interest in tinkering, and there is a huge pile of money up for grabs.
What It Tells Us
The clearest lesson we see is that nobody actually cares to do the hard work of mechanism design and face the realities of market feedback. There are an awful lot of "researchers" in web3 that look at obscure topics and navel-gaze for years.
ENS was, and is, a simple product that would make a great place to experiment with mechanism designs. That did not happen. To the extent the DAO was always a bit of sham that is kind of the right outcome even if it feels a bit unsatisfying.
Is the reason that the team which controlled the treasury refused to fund projects? Maybe. Though it is not like developing simple smart contracts for this stuff would be super expensive. Is the reason that it worked perfectly out of the box? Come on that is ridiculous. It is software.
We are going to assert at least part of the reason was that proposing, and trialing, new mechanisms for registering ENS names would yield instant feedback on those mechanisms. And many "researchers" do not want real market feedback on their designs; they want grants to continue to look at whatever obscure self-created problems they find interesting.
It is not like launching an ENS competitor would have been terribly difficult or expensive. Even if the team would not fund you: go build it. Cloning the system and modifying the mechanisms was never that hard or expensive.
Reasonable people can argue over whether the founders are just trying to swipe the treasury here. And they can argue whether or not that is reasonable given what has transpired over the past few yeas. What you cannot argue is that massive demand to improve ENS was stifled by the team's tight-fisted control over those very same funds. ENS is a sort of copy-cousin of DNS. It is not, was not, and will never be some amazing new super-innovative idea. The name is so similar they were not even trying. So launching ENS2 or whatever was always on the table. The barrier to entry has always been so low it is not credible to claim the team blocked competitors.
This is a story of neglect and a preference for intellectual games over market feedback. And it is, overall, a fairly sad story. Except from the perspective of the team that runs a thing with real revenues that is going to get to control all that money now. For them it is pretty good.
