| Standard author | Nick Johnson |
|---|---|
| Created | 2016-04-04 |
| Document type | ERC-137 / ENSIP-1; ENS interface specification; Final |
| Project | Ethereum Name Service (ENS) |
| License | Not stated on the ERC-137 page; implementation licenses are separate |
| Official source | ERC-137 |
The original ENS interface standard, now titled ERC-137: Ethereum Domain Name Service — Specification, describes how applications resolve human-readable names to resources. Nick Johnson is its listed author; the creation date is April 4, 2016. Its normative interface separates naming responsibilities and deliberately leaves registration policies to registrars. Its appended contracts are illustrative implementations, not current deployment instructions. [1]
The Original Architecture
A registry maps a name’s node to its owner, resolver and caching TTL. A registrar allocates names in a namespace; a resolver answers resource lookups. In the basic flow, the client finds the resolver in the registry, then queries the requested record. Resolver capabilities are discovered through supportsInterface. For the original addr(bytes32) interface, a missing record returns the zero address; clients must treat it as unresolved rather than sending funds there. [1]
This modular design allows allocation policy and record storage to differ. Changing a name’s resolver is different from changing a record in the resolver. Owning a registry node also does not imply that every application reads the same record type or that every resolver supports every extension.
Normalize Before Hashing
ENS uses a 32-byte namehash node derived recursively from normalized labels. For the illustrative name alice.eth, the computation starts from the zero root, incorporates eth, then alice. Labelhash hashes a single label and is different from the full node. Hashing derives an identifier; it neither registers the name nor proves control over it. [2]
The 2016 specification refers to UTS-46 normalization. Current ENS documentation specifies ENSIP-15, which adds rules for valid emoji sequences and common spoofing cases. Integrations should use a compatible normalization library rather than treating lowercasing alone as sufficient. Rejected input should be handled as invalid, not silently hashed into a different name. [2]
Modern Resolution and Display
The public resolver supports extensions for text, content hashes, multicoin addresses and other records. Custom resolvers also exist, so applications should discover the selected resolver and supported interfaces rather than hardcoding one implementation. A record’s existence is distinct from the name’s ownership, and an Ethereum address record is not automatically a valid payment destination for another chain. [4]
Reverse resolution starts with an address and returns a preferred name. ENS documentation requires a subsequent forward lookup to confirm that the name resolves back to that address; if it does not, display the address instead. This protects a display from an unverified name claim. Forward/reverse agreement verifies that particular mapping, not a person’s real-world identity or the trustworthiness of an investment. [3]
Registration and Wrapping Are Separate Layers
Current .eth registrar documentation separates the BaseRegistrar’s ownership and transfer functions from the controller’s registration, renewal and pricing functions. Registration uses commit-reveal to make a pending name request harder to front-run. Unwrapped second-level .eth registrations use ERC-721 ownership. Renewal and expiry rules belong to this registration system; the original resolution standard does not fix a universal registration fee or lifetime for every ENS namespace. [5]
The Name Wrapper represents wrapped names as ERC-1155 tokens and introduces fuses controlling capabilities. Parent and name-owner permissions differ, and wrapping changes the management model. A subname’s guarantees therefore depend on its actual wrapped state, permissions and expiry. A token on a marketplace alone does not establish that the parent has permanently surrendered all control. [6]
Namehash Is Not DNSSEC
DNS integration uses a separate mechanism: DNSSEC verifies signed DNS records and a chain of trust. ENS documentation describes both onchain import and offchain-fetched proofs verified during resolution. This is different from merely computing namehash. DNS names brought into ENS remain subject to their DNS domain’s administration and supported configuration; ENS does not automatically remove that dependency. [7]
Scope and Practical Limits
This reference covers the 2016 interface and documented integration layers. It does not measure current registration totals, wallet market share or token value. Before using a resolved record, check the exact normalized name, chain, record type and current resolver result. Later ENS proposals and deployment changes should be assessed under their own versions rather than attributed to the original standard.
Social Media Sentiment
Not applicable as a token sentiment rating: this is a naming-standard reference. The ENS governance token and community discussion require separate, current evidence; no popularity or investment sentiment claim is inferred from the technical documentation.
Last updated: 2026-10
Related Terms
- Ethereum — network context for the original registry.
- Smart Contract — programmable registries and resolvers.
See Also
- Ethereum Name Service glossary entry — broader project introduction.
- ERC-721 interface reference — token ownership and interface requirements.
Sources
- Johnson, N. (2016). ERC-137: Ethereum Domain Name Service — Specification. — Original standard, registry/resolver interfaces, namehash and missing-address handling.
- ENS Docs. Name Processing. — Current ENSIP-15 normalization and distinctions between namehash and labelhash.
- ENS Docs. Resolution Process. — Forward lookup, resolver interfaces and forward verification of reverse names.
- ENS Docs. Public Resolver. — Record extensions, custom resolvers and interface discovery.
- ENS Docs. ETH Registrar. — BaseRegistrar/controller responsibilities, registration, renewal and ERC-721 ownership.
- ENS Docs. Name Wrapper Overview. — ERC-1155 wrapping, permissions and subname controls.
- ENS Docs. DNS Registrar. — DNSSEC verification, DNS import and offchain-assisted resolution.