EIP 162: Initial ENS Hash Registrar

Return to Ethereum ERCs

Note: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference.

Data sheet for Initial ENS Hash Registrar

Title	Initial ENS Hash Registrar
Author	Maurelian, Nick Johnson, Alex Van de Sande
Status	Final
Created	2016-10-25
Description	http://eips.ethereum.org/EIPS/eip-162
Specification	http://eips.ethereum.org/EIPS/eip-162#Specification
Category	ERC

Abstract

This ERC describes the implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS). The corresponding source code is here.

For more background, refer to EIP 137.

Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts.- EIP 137A well designed and governed registrar is essential to the success of the ENS described in EIP 137, but is described separately in this document as it is external to the core ENS protocol.

In order to maximize utility and adoption of a new namespace, the registrar should mitigate speculation and “name squatting”, however the best approach for mitigation is unclear. Thus an “initial” registrar is proposed, which implements a simple approach to name allocation. During the initial period, the available namespace will be significantly restricted to the .eth top level domain, and subdomain shorter than 7 characters in length disallowed. This specification largely describes @alexvandesande and @arachnid’s hash registrar implementation in order to facilitate discussion.

The intent is to replace the Initial Registrar contract with a permanent registrar contract. The Permanent Registrar will increase the available namespace, and incorporate lessons learned from the performance of the Initial Registrar. This upgrade is expected to take place within approximately 2 years of initial deployment.