# ERC-162: ENS .eth Registrar Source: https://www.eipsfordesigners.com/standards/ERC-162 Agent brief: https://www.eipsfordesigners.com/standards/ERC-162/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-162 Last reviewed: 2026-05-25 Last updated: 2026-05-25 | Field | Value | | --- | --- | | Status | Final | | Chain | ethereum | | Category | Comprehension & Display | | Journey stages | Authentication & Identity | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/erc-162 | | Discussion search | https://ethereum-magicians.org/search?q=ERC-162 | ## UX Impact Users acquire ENS names through blind auctions — bid privately, highest bidder wins, pays second-highest price. Design implications: guide users through 3-day bid reveal process with timeline UI, show deposit/refund status clearly, explain Vickrey auction mechanics simply, countdown timers for auction phases. Design decisions: how much auction complexity to expose vs abstract away, whether to show competitor activity, handling the 72hr bidding + 48hr reveal lifecycle, surfacing name availability timing. ## Summary Users acquire ENS names through blind auctions — bid privately, highest bidder wins, pays second-highest price. ## For Designers - You can show auction phases on a timeline with countdown timers. - Your reveal flow can explain why revealing matters before deadline. - You can surface deposit and refund status clearly. ## Applicability ### When to Use - Your product helps users acquire ENS .eth names. - Auction mechanics need step-by-step guidance. - Users must manage bid reveal deadlines. ### When to Avoid - Names acquired via direct purchase or L2 gateways only. - Your app does not touch ENS registration. - Users only resolve names, never register. ## Problems It Solves ### Inconsistent behavior across apps Impact: high Old way: Each team reinvents copy and edge cases New way: Shared standard gives predictable UX patterns ### Users surprised by on-chain rules Impact: high Old way: Generic transfer UI fails at submit time New way: Standard-aware UI sets expectations upfront ### Support burden from opaque errors Impact: medium Old way: Raw revert reasons in toasts New way: Mapped states explain what to do next ## Anti-Patterns ### Hiding standard-imposed restrictions until submit Severity: critical Users feel tricked when actions fail at the last step Instead: Show eligibility and badges before the primary CTA ### Protocol jargon in user-facing copy Severity: high Non-technical users cannot consent informedly Instead: Use outcome language with optional technical disclosure ### No fallback when wallet lacks support Severity: high Dead-end flows increase churn Instead: Explain limitation and offer alternate path or network ## Design Decisions ### How much protocol detail do users see? Recommendation: Lead with outcomes; tuck identifiers behind review. Rationale: Users decide on consequences, not function selectors. ### What happens when support is missing? Recommendation: Block with explanation and fallback path. Rationale: Silent failure feels like a broken product. ### How do you label restricted assets? Recommendation: Use persistent badges for non-transferable, locked, or expiring states. Rationale: Hidden restrictions cause rage-quits at transfer time. ## States to Design ### Ready Trigger: Prerequisites met. User need: Understand what happens next. Design response: Enable primary action with plain-language preview. ### Awaiting signature Trigger: Wallet prompt open. User need: Know what they are approving. Design response: Mirror human-readable summary in app and wallet. ### Pending Trigger: Transaction submitted. User need: Confidence it is progressing. Design response: Show status strip with explorer link. ### Succeeded Trigger: On-chain confirmation. User need: See updated ownership or balance. Design response: Celebrate outcome and show new state clearly. ### Failed or reverted Trigger: Validation or execution failed. User need: Fix or retry without guessing. Design response: Name the failed constraint and offer a concrete next step. ## Vocabulary - Use "Your balance / Your item" instead of "Token ID / Token contract": Ownership language matches mental models. - Use "Cannot transfer yet" instead of "Transfer reverted": Explain restriction without EVM vocabulary. - Use "Confirm in wallet" instead of "Sign transaction": Matches wallet UX users already know. ## What to Prototype First ### Primary happy path Prove the core user promise before edge cases. Covers: Success state, Clear outcome copy - Primary CTA - Confirmation feedback - Next step ### Blocked or unsupported state Users discover limits when wallets or chains lack support. Covers: Unsupported wallet, Wrong network - Plain-language reason - Fallback action ### Failure recovery Trust breaks when errors look like bugs. Covers: User rejection, Transaction revert - Retry path - Support context ### Advanced disclosure Power users need technical detail without cluttering the default path. Covers: Contract address, Token ID, Raw status - Expandable section - Copy buttons - Explorer link ## Mental Model ### Commit phase Bidders submit a hidden hash of their bid plus deposit. The UI must explain that bids are sealed until reveal. ### Reveal phase Before deadline, bidders reveal actual bid amount. Missing reveal loses the deposit, so countdown UX is critical. ### Auction close Highest valid bid wins the name. Second-price rules mean the winner pays one increment above the second-highest bid. ### Settlement Winner receives the name registration, losers get deposits back minus gas. Show refund status for non-winners. ### Registration After winning, the name follows normal ENS lifecycle. Connect auction outcome to name management in your product. ## Seen in the Wild - ENS App: Primary interface for .eth name registration and auctions. (https://app.ens.domains/) - ENS Vision: Market analytics for ENS name availability and pricing. (https://ens.vision/) - OpenSea ENS: Secondary market for acquired ENS names. (https://opensea.io/collection/ens) ## UX Patterns ### Auction Phase Timeline Visual timeline of bid, reveal, and settlement. Components: PhaseTimeline, CountdownTimer, PhaseLabel User flow: - User starts bid - Timeline shows current phase - Countdown to reveal deadline - Settlement shows final price Mockup registry key: `concept/nft-gallery` (React UI on the live standard page). ### Reveal Reminder Prominent reminder before reveal deadline. Components: RevealBanner, RevealCTA User flow: - Bid period ends - Reminder appears - User reveals bid - Avoids lost deposit Mockup registry key: `concept/verify-safety` (React UI on the live standard page). ## Related Standards - ERC-137: Forward resolution for registered names - ERC-181: Reverse resolution after registration ## Technical Notes ERC-162 Vickrey auctions require reveal within 48 hours or bids are lost.