{"id":"ERC-162","name":"ENS Initial Registrar (historical)","status":"Final","chain":"ethereum","category":{"id":"comprehension","name":"Comprehension & Display","description":"Making blockchain data readable to humans"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"}],"uxImpact":"Historical reference: ERC-162 describes the obsolete initial ENS .eth auction registrar. Its official specification status is Final, but this auction is not the current registration flow. Current ENS registration uses a commit, wait and register process rather than bids and reveals.","historical":true,"officialUrl":"https://ercs.ethereum.org/ERCS/erc-162","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-162","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-162","type":"official-spec"},{"label":"ENS initial registrar archive","url":"https://docs.ens.domains/ensip/2/","type":"reference"},{"label":"Current ENS registration","url":"https://support.ens.domains/en/articles/7900438-why-does-eth-registration-take-three-steps","type":"reference"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"Historical reference: ERC-162 describes the obsolete initial ENS .eth auction registrar. Its official specification status is Final, but this auction is not the current registration flow. Current ENS registration uses a commit, wait and register process rather than bids and reveals.","designerTakeaways":["Label the initial registrar as historical and unavailable for new registrations.","Explain the historical second-price outcome and deposit refund rules accurately.","Link current .eth registration to the current registrar workflow."],"applicability":{"whenToUse":["You are explaining historical ENS auctions or interpreting old registrar transactions.","An archive needs to distinguish bids, refunds and retained collateral."],"whenToAvoid":["You are building a current .eth registration flow. Use the current ENS registrar documentation.","You need evidence that an auction is available now; Final describes the specification, not an active service."]},"mentalModel":[{"label":"Commit phase","description":"Bidders submit a hidden hash of their bid plus deposit. The UI must explain that bids are sealed until reveal."},{"label":"Reveal phase","description":"Bidders revealed the actual bid within the reveal period. Late or invalid reveals followed separate refund and penalty rules, so historical displays must use the recorded outcome rather than promise a full refund."},{"label":"Auction close","description":"The highest valid bid won. The final value was the second-highest bid, subject to the registrar minimum, not an increment above it."},{"label":"Settlement","description":"The winner retained the required value in a deed as collateral. A valid non-winning revealed bid received a 99.5% refund; other outcomes followed their own refund and penalty rules. Gas was an additional cost."},{"label":"Registration","description":"These are historical registrar records. Do not present an old auction win or collateral balance as the current registration lifecycle."}],"problemsSolved":[{"problem":"Old ENS records are mistaken for current registration steps","oldWay":"Present bid and reveal actions to someone registering a name today","newWay":"Label the auction historical and direct new registrations to the current ENS registrar","impact":"high"}],"uxPatterns":[],"antiPatterns":[{"pattern":"Offering the initial auction for new registrations","why":"ENS no longer uses this registrar for new .eth registrations","instead":"Label the auction as historical and link to current registrar guidance","severity":"critical"},{"pattern":"Relabeling the official ERC as Withdrawn","why":"The official specification is Final even though its implementation is obsolete","instead":"Keep the official status and describe the historical implementation separately","severity":"high"},{"pattern":"Treating collateral as a permanent purchase fee","why":"The old deed balance and bid refunds have different settlement rules","instead":"Show retained collateral, refund amounts, penalties and gas separately","severity":"high"}],"specConstraints":[{"id":"registrar-balance-security","constraint":"The initial registrar holds Ether without an explicit limit and must be designed securely.","appliesTo":"infrastructure","normativity":"normative","specQuote":"**Security:** The registrar will hold a balance of ether without an explicit limit. It must be designed securely.","specSection":"Motivations","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#motivations","designImplication":"Treat this historical registrar as a high-value custody system and do not reuse its balance assumptions for a current registration flow."},{"id":"ens-root-control","constraint":"The ENS root owner should assign only .eth to the initial registrar and should be controlled by a multisig.","appliesTo":"infrastructure","normativity":"normative","specQuote":"This restriction is enforced by the owner of the ENS root node who should not assign any nodes other than `.eth` to the Initial Registrar. The ENS's root node should be controlled by multiple parties using a multisig contract.","specSection":"Specification > Initial restrictions","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#initial-restrictions","designImplication":"Historical registrar administration should display root scope and multisig authority rather than implying a single-owner trust model."},{"id":"name-hash-input","constraint":"Initial-registrar submissions hash the subdomain label with Ethereum’s sha3, not an EIP-137 namehash.","appliesTo":"application","normativity":"normative","specQuote":"Names submitted to the initial registrar must be hashed using Ethereum's sha3 function. Note that the hashes submitted to the registrar are the hash of the subdomain label being registered, not the namehash as defined in EIP 137.","specSection":"Specification > Name format for hash registration","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#name-format-for-hash-registration","designImplication":"Label the historical hash input clearly and prevent users from confusing a label hash with a current ENS namehash."},{"id":"auction-bid-phase","constraint":"A name auction has a 72-hour bidding period using sealed bids and Ether payment.","appliesTo":"application","normativity":"normative","specQuote":"3. **Auction:** Once the auction for a name has begun, there is a 72 hour bidding period. Bidders must submit a payment of ether, along with sealed bids as a hash of `sha3(bytes32 hash, address owner, uint value, bytes32 salt)`. The bidder may obfuscate the true bid value by sending a greater amount of ether.","specSection":"Specification > Auctioning names","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#auctioning-names","designImplication":"If showing historical data, separate bid creation, payment, and deadline states and explain that the mechanism is not the current ENS registration flow."},{"id":"auction-reveal-phase","constraint":"After bidding, a 48-hour reveal period requires true bid parameters and applies refund ratios.","appliesTo":"application","normativity":"normative","specQuote":"4. **Reveal:** After the bidding period, a 48 hour reveal period commences. During this time, bidders must reveal the true parameters of their sealed bid. As bids are revealed, ether payments are returned according to the schedule of \"refund ratios\" outlined in the table below. If no bids are revealed, the name will return to the Open state.","specSection":"Specification > Auctioning names","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#auctioning-names","designImplication":"Make reveal deadlines, refund status, and unrevealed-bid outcomes explicit in any archival auction view."},{"id":"auction-finalization","constraint":"After reveal, the winning bidder must finalize the auction before the ENS subnode owner is recorded.","appliesTo":"application","normativity":"normative","specQuote":"5. **Owned:** After the reveal period has finished, the winning bidder must submit a transaction to finalize the auction, which then calls the ENS's `setSubnodeOwner` function, recording the winning bidder's address as the owner of the hash of the name.","specSection":"Specification > Auctioning names","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#auctioning-names","designImplication":"Distinguish winning a historical auction from completing ownership finalization and show the pending-finalization state."},{"id":"auction-timing","constraint":"The initial registrar defines fixed auction/reveal/launch windows and a minimum locked price.","appliesTo":"application","normativity":"normative","specQuote":"|        Name        |                                            Description                                             |   Value    |\n|--------------------|----------------------------------------------------------------------------------------------------|------------|\n| totalAuctionLength | The full time period from start of auction to end of the reveal period.                            | 5 days     |\n| revealPeriod       | The length of the time period during which bidding is no longer allowed, and bids must be revealed. | 48 hours   |\n| launchLength       | The time period during which all names will become available for auction.                          | 8 weeks    |\n| minPrice           | The minimum amount of ether which must be locked up in exchange for ownership of a name.           | 0.01 ether |","specSection":"Specification > Auctioning names > Registrar Parameters","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#registrar-parameters","designImplication":"Show the historical phase durations and minimum price as explicit configuration, not as current ENS registration guidance."},{"id":"sealed-bid-generation","constraint":"A registrar helper takes bid parameters and returns the sealed bid hash used in an auction.","appliesTo":"application","normativity":"normative","specQuote":"- Takes the parameters of a bid, and returns the sealedBid hash value required to participate in the bidding for an auction. This obfuscates the parameters in order to mimic the mechanics of placing a bid in an envelope.","specSection":"Specification > Registrar Interface","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#registrar-interface","designImplication":"If presenting a historical bid flow, show the sealed-bid generation step separately from the public bid amount."},{"id":"name-owner-control","constraint":"Updating the ENS node owner must be callable only by the current owner.","appliesTo":"account-implementation","normativity":"normative","specQuote":"- Update the owner of the ENS node corresponding to the submitted hash to a new owner. This function must be callable only by the current owner.","specSection":"Specification > Registrar Interface","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#registrar-interface","designImplication":"Owner-management UI must show the current-owner authority and reject apparent actions from unauthorized accounts."},{"id":"registrar-anti-squatting","constraint":"A registrar SHOULD mitigate speculation and name squatting, while recognizing that the best mitigation approach may be uncertain.","appliesTo":"infrastructure","normativity":"rationale","specQuote":"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.","specSection":"Abstract","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#abstract","designImplication":"Explain the registrar's allocation policy and its limits; do not frame availability rules as proof that every name is fairly allocated."},{"id":"bid-obfuscation-option","constraint":"A bidder MAY send more Ether than the true bid value to obfuscate the bid during the sealed phase.","appliesTo":"application","normativity":"normative","specQuote":"The bidder may obfuscate the true bid value by sending a greater amount of ether.","specSection":"Specification > Auctioning names","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#auctioning-names","designImplication":"Separate the hidden bid value from the Ether deposit in archival auction UI and do not imply that the deposited amount is the bidder's true valuation."},{"id":"deed-transfer-control","constraint":"A deed owner MAY transfer an owned name's deed, transferring ownership and control to another account.","appliesTo":"application","normativity":"normative","specQuote":"A deed for an owned name may be transferred to another account by its owner, thus transferring ownership and control of the name.","specSection":"Specification > Deeds","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#deeds","designImplication":"Present deed transfer as an ownership-and-control change with a clearly identified recipient, not as a simple account alias update."},{"id":"deed-release-option","constraint":"After one year of registration, a hash owner MAY relinquish ownership and receive the deed value back.","appliesTo":"application","normativity":"normative","specQuote":"After 1 year of registration, the owner of a hash may choose to relinquish ownership and have the value of the deed returned to them.","specSection":"Specification > Deeds","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#deeds","designImplication":"Show relinquishment as a time-gated option that ends ownership and returns collateral, distinct from a routine refund."},{"id":"expired-bid-cancellation","constraint":"After more than two weeks and five days, anyone MAY cancel a still-sealed bid to collect a small reward.","appliesTo":"application","normativity":"normative","specQuote":"A bid which remains sealed after more than 2 weeks and 5 days may be cancelled by anyone to collect a small reward.","specSection":"Specification > Deeds > Refund schedule > Notes","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#refund-schedule","designImplication":"Represent an expired sealed bid as cancellable with a separate reward outcome, and distinguish it from bidder-initiated refund paths."},{"id":"registrar-deployment-order","constraint":"The Initial Registrar SHOULD be deployed after ENS, then assigned the .eth node by the root-owning multisig.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The Initial Registrar requires the ENS's address as a constructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the `eth` node.","specSection":"Specification > Deployment and Upgrade process","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#deployment-and-upgrade-process","designImplication":"Treat deployment order and root assignment as infrastructure prerequisites; expose the active registrar and .eth scope clearly in administrative status views."},{"id":"registrar-upgrade-process","constraint":"The Initial Registrar SHOULD be replaced by a Permanent Registrar after approximately two years using the specified upgrade process.","appliesTo":"infrastructure","normativity":"normative","specQuote":"The Initial Registrar is expected to be replaced by a Permanent Registrar approximately 2 years after deployment. The following process should be used for the upgrade:","specSection":"Specification > Deployment and Upgrade process","specUrl":"https://ercs.ethereum.org/ERCS/erc-162#deployment-and-upgrade-process","designImplication":"For archival or migration views, show the registrar transition as an explicit lifecycle with ownership handoff and unresolved deed migration states."}],"technicalNotes":"ERC-162 remains an officially Final historical specification. ENSIP-2 marks the initial hash registrar obsolete. For archive displays, distinguish the second-price value, retained deed collateral, valid non-winning bid refunds of 99.5%, late/invalid reveal rules and transaction gas. Current registrar registration and renewal have different mechanics.","relatedStandards":[{"id":"ERC-137","relationship":"Forward resolution for registered names"},{"id":"ERC-181","relationship":"Reverse resolution after registration"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-162","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-162","type":"discussion"},{"label":"ENS initial registrar archive","url":"https://docs.ens.domains/ensip/2/","type":"reference"},{"label":"Current ENS registration","url":"https://support.ens.domains/en/articles/7900438-why-does-eth-registration-take-three-steps","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-162","markdown":"https://www.eipsfordesigners.com/standards/ERC-162/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-162/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-162","official":"https://ercs.ethereum.org/ERCS/erc-162","discussion":"https://ethereum-magicians.org/search?q=ERC-162"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}