Proposed design outline for the permanent registrar


First, some useful background reading:

Second, what are our goals for the .eth registrar? Here’s my proposed list, in rough order of importance:

  1. Name stability. The owner of a name should be able to retain ownership of that name for as long as they’re prepared to pay for renewals. Other parties should not be able to acquire a name through inaction (except when it would naturally expire anyway), or force the owner to pay an increased price to retain it.
  2. Fair allocation. Names should, wherever possible, end up in the hands of the people who can put them to the best use.
  3. Usability. Registrations and renewals should be as simple as possible.
  4. Anti-squatting. We should disincentivise squatting, particularly broad-based attempts to buy up large parts of the namespace for resale, to the greatest degree possible.
  5. Affordability. Prices for rent and registration should be set at the minimum level required to achieve the above goals.

With those goals in mind, here is an outline of my current working proposal for the new registrar and the migration process to it:

  1. A one-off auction will be held, during which people can bid on names between 3 and 6 characters in length. This will likely be a vickery-style auction, like the current registrar uses, but over an extended duration (at least a month). The winning bids will go towards funding ENS development, and all winning bidders will receive a 1 year registration on the name.
  2. The new registrar’s interface will be clearly defined at least a month in advance of activation, to permit existing tools time to update their functionality to support it.
  3. The new registrar will be deployed and activated at an agreed upon time. At that point, all existing names - both legacy names and those from the short name auction, will be eligible for transfer.
  4. Anyone wishing to transfer a name from the previous registrar has a year from the date of deployment of the new registrar to do so. When they do, the expiration of their name is set to 1 year after the registrar deployment date. The same rules apply to those who won names in the short name auction.
  5. A fixed yearly rent will be assessed on each name. This will be a flat rate for all existing names, but may scale up for shorter names (eg, 3 character names may cost significantly more to renew than 7 character names, due to the scarcity of short names).
  6. Anyone can extend the registration duration of any name at any time by calling a function on the registrar and paying the appropriate fee. There is no limit on how long the renewal duration can be - if you wish to renew your name for 100 years, you can do so as long as you pay the current price for that. This also enables ‘locking in’ a favorable price.
  7. Rent prices will initially be set by a multisig controlled by ENS, and adjusted based on fluctuations in the price of ether and other market conditions. In time we would like to develop a mechanism to set prices automatically.

Unanswered questions:

  • What form should the short name auction take?
  • What registration price is sufficient to discourage large scale squatting, but affordable to regular users?
  • How much more expensive should short names be, if at all?
  • What should be done with funds over and above those required to pay for ongoing development costs?

Please don’t hesitate to offer input on everything here - goals, proposal, and questions.


5th question -

  • What should the initial rent price be and how are initial and ongoing rent prices determined over time?

I’d suggest funding the ongoing ENS Foundation costs for 2 years. Excess can be used to give grants to individuals and teams working to expand ENS’ reach. This could be through building apps, add-on functionality, integrating with existing infrastructure, etc.


Given a good pricing oracle, could we allow for rent to be paid in multiple currencies? Such as DAI / ETH?


I’m reluctant to add dependencies on higher level components into ENS - as base-layer infrastructure, we shouldn’t break if higher level stuff breaks, as it risks nasty dependency cycles. That said, we could use some kind of oracle like the DAI, as long as we provided a fallback option.


Am I reading correct that the ENS foundation intends to now keep all existing and new deposits on names to put towards development as we transition towards a new registrar? And then the ENS foundation is free to do as they wish with these funds with no input from the stakeholders of the system? What stops a hostile takeover, or from current devs deciding they are no longer interested in working on the project? How is this value extraction not potentially more harmful than helpful for adoption? The original deposits should remain with the names until release, not go towards the ENS foundation.

I also don’t really like the idea of rent funding some group of developers ad infinitum. It could be a value drain on the system after things are pretty well developed and mostly autonomous. Where does that rent go when the ENS foundation completes its work? Is it even feasible to think ENS will be “finished” one day? Or are there too many unknown unknowns to tell right now? Is rent really preventing squatters in this proposal, or just fueling development? If it’s the latter, total rent should be a function of how much development costs.

There could be a system where stakeholders in ENS, possibly how much eth is deposited into names, have voting rights over how much rent is collected, and where the funds go. Developers would make proposals of how much rent they need and where the money would go towards development, and then stakeholders could vote on the proposals. Those with stake in the system would most likely want to see the system succeed, and thus would vote appropriately for rent that would help the system improve without generating a surplus in tax that we don’t know what to do with. Squatters may vote against the rent, but they will have a smaller vote as most of those mass registered names have .01 ETH deposits vs 1000 ETH in larger names.

Your proposal in my opinion gives too much power to the ENS foundation since it both sets the price of rent, then collects it, then spends it without community oversight. ENS keeping deposits also begins to look more like a company (Cryptokitties?) where massive profits are extracted rather than staying in the system. I think this would be detrimental to adoption in the name of driving out squatters.

There is also talk in the shorter name thread where people think the ENS foundation should reserve names for companies or projects. That idea would allow ENS to dictate who gets a free pass and does not need to fork over a big deposit to them, and who they want to take a deposit from, corrupting the system. I am completely against this type of intervention, and I think the system should be ruled by economics and 2nd layer whitelisting instead.

I appreciate all the work being done, and I think we need to create the best possible game moving forward to ensure a functional system.


Sorry I may have misread the part about existing deposits going to the ENS foundation, and it seems just the new short name deposits would. I stand by the rest of my criticism.

  1. Anyone can extend the registration duration of any name at any time by calling a function on the registrar and paying the appropriate fee. There is no limit on how long the renewal duration can be - if you wish to renew your name for 100 years, you can do so as long as you pay the current price for that. This also enables ‘locking in’ a favorable price.

Doesn’t this encourage squatting? Shouldn’t prepaid rent work on increasing increments? That would encourage yearly renewals which would benefit active projects as opposed to future prospectors—unless transfer of ownership wasn’t allowed.


I agree that we should maybe look into this.


I don’t think ENS will be “finished”, but it’s reasonable to assume less development effort will be required in than is required today. I’d like to see any excess rent be used to fund community initiatives, primarily those related to naming and usability.

As I said earlier in the principles, I don’t think rent should be used primarily as a way to fund development; its primary use is to discourage squatting. It clearly does that; if the rent price was zero, we’d reasonably see every conceivable name snapped up and resold.

We’ve considered this too, but your concern about takeover goes double if it’s governed by a system that depends on votes by stake deposited, rent paid, or domains owned. It’d be far too easy for a large-scale squatter to take over the system, or for someone to register domains en-masse just for this purpose, and thus get effective control of fund distribution.

It’s very easy for a squatter to artificially generate deposits if they wish to have a larger voice in governance. We also can’t rely on deposits on an ongoing basis, since these will be going away.

Being able to preregister for a long period is a pretty attractive option for use-cases where name stability is important and the name will be controlled by a contract.

I don’t think this will encourage squatting - large scale squatters will simply set up an automated process to renew domains for them if it’s more economic to do so. They also have little incentive to register for long periods, as they hope to be able to sell the domain off to someone else in fairly short order.


+1 on @chris-remus idea of assigning the rent to also grants (beyond ENS development)

I’d suggest funding the ongoing ENS Foundation costs for 2 years. Excess can be used to give grants

+1 on using DAI with a fallback like mentioned by @decanus and @nickjohnson

In general I feel that a lot of proposed mechanisms for the rent and for how the registry should work are designed with an anti-squatter objective, but I think that this adds complexity to something that could be potentially easy and that it would be better to think up an independent mechanism to discourage squatters
initial ideas here, (that incidentally would make the rent part of the incentives for anti-squatter hunters)

In this idea there is also the potential to both do a rent model as well as lock up eth
(maybe the first year you have to pay 2x the rent, one part goes to pay the service and 1 part stays locked into the domain for making the anti-squatter incentive mechanism work)

Like this the Squatter has immediately payed 2x as much as it initially would have had and is potentially setting himself up for loosing all that locked ETH, across all his domains, because once one domains has been successfully claimed as “squatted”, and therefore lost the locked ETH, potentially all his other domains can be easily claimed as squatted too.

Specific Requests for the new registrar

the new registrar should make possible to know how many domains are owned by a given account
(and possibly even which ones, although I understand that this last feature goes against the privacy preserving setup of ENS and therefore is not desirable)

The reason to see the number of owned domains are

  • to make it clearer to a possible analysis to recognise if a user is a squatter (through squatter-oracle process).

  • to make it more complicated to squatters to manage their domains if they want to hide by using multiple accounts to own their domains


  • this is based on the assumption that a squatter is someone who owns a large number of domains, but as described in the post also the speculative-squatter could also be squatting only a single high valued domain

  • the number of domains owned is a weak signal that someone is a squatter, and it could include false positives: perfectly legitimate organizations or individuals who own, manage and use many domains.


We can’t build any mechanism that relies on counting the number of domains a user has registered; if we do so squatters will simply start using a new account for each registration.

I also don’t think we can include dispute resolution as a base layer in the new registrar, for practical, principle, and time-related reasons.

It’s possible for anyone to determine this based on blockchain records today. I don’t think there’s a benefit in baking extra record keeping of this kind into the registrar.