Handshake

Summary

Handshake is a permissionless, proof-of-work Layer 1 blockchain whose sole purpose is to serve as a decentralized alternative to ICANN's DNS root zone — the file that maps top-level domains (like .com) to their authoritative name servers. Instead of a central registry granting TLDs, Handshake auctions previously-unclaimed name strings to the public; winners record a root-zone entry directly on the Handshake chain, and full nodes replicate that root the way today's resolvers replicate ICANN's. The project was designed starting around 2017-2018 by a group associated with the Bitcoin infrastructure company Purse and the Bcoin node implementation — publicly credited as Joseph Poon (co-creator of the Lightning Network and Plasma), Andrew Lee (Purse/Private Internet Access), Christopher Jeffery (Bcoin creator), and Boyma Fahnbulleh — and was backed by roughly $10.2 million from investors including a16z, Sequoia, Founders Fund, and Polychain. Handshake reserved the top ~100,000 Alexa-ranked domain names for their existing owners (with a sunrise/claim process) and gave away roughly 85% of the initial 1.36 billion HNS supply to open-source developers via a decentralized, criteria-based airdrop, rather than to the founding team or investors. Mainnet launched February 3, 2020. All other names are released for public auction on a rolling weekly schedule using a blind, second-price (Vickrey) mechanism, with the losing bid amount burned. Six years on, the protocol remains technically live — still mined, still auctioning names — but has failed to achieve its founding goal: no mainstream browser ever added native Handshake resolution, registrar/marketplace support has been contracting (Namecheap wound down its Handshake TLD support and sold its Namebase marketplace in 2026), and HNS has fallen more than 99% from its 2021 high.

Design (Mechanism)

• Decentralized root zone. Rather than ICANN's root servers, each Handshake full node independently derives the root zone from consensus over the blockchain. A name's owner controls a Handshake "resource" record (an analog to a zone file) that can point to DNSSEC-style keys and name servers, which downstream resolvers (via a Handshake-aware DNS resolver like hnsd or a plugin) can chase down to a normal, ICANN-rooted domain if desired.
• Weekly release schedule, not a one-time land grab. Of an estimated universe of eligible strings, names are opened for auction in weekly batches over roughly the first year post-launch, spreading out the auction process rather than letting a single mint event capture everything at once.
• Reserved names + sunrise period. The top tens of thousands of names by Alexa rank were pre-reserved for their real-world owners/trademark holders, who got a 90-day claim window before any name entered the open, competitive auction — an explicit attempt to avoid pure squatting on already-meaningful brands.
• Blind bidding with an obfuscating "blind" amount. Each auction has a ~5-day open (bidding) period followed by a ~10-day reveal period. A bidder locks up bid + blind HNS; only the total lockup is publicly visible during bidding, while the true bid is hidden until the reveal phase. This lets bidders disguise a low true bid behind a larger lockup.
• Second-price (Vickrey) settlement. After reveals, the highest revealed bid wins and mints the name — but the winner only pays (i.e., loses) the second-highest revealed bid amount. Their remaining lockup (bid minus the clearing price) is refunded; any unrevealed bids are forfeited to the winner's excess-payment pool as an anti-griefing penalty.
• Burn, not treasury. The clearing payment is provably burned rather than routed to a foundation, treasury, or previous owner — the protocol accrues no fee revenue from naming; the auction exists purely to allocate a scarce namespace fairly under contention, not to fund anything.
• Fair-launch distribution. Around 67.5%+ of the initial coin supply went to open-source developers (via GitHub/PGP-keyring/Hacker News/Keybase eligibility snapshots) and FOSS-adjacent nonprofits rather than to founders or funders, an explicit attempt to bootstrap legitimacy and broad-based node/miner participation instead of an insider pre-mine.

Outcome

Technically successful, commercially unsuccessful (so far). The chain launched on schedule, the airdrop and auction mechanism functioned as specified, and the network has continued mining blocks and settling name auctions for over six years — by mid-2020s counts, well over 10 million names had been registered on-chain. But "own a name people can actually reach" never materialized at scale: no major browser (Chrome, Firefox, Safari, Edge) ever shipped native Handshake resolution, so viewing an HNS site requires a special resolver, browser extension, or custom DNS configuration — a friction point that capped it to a technically-inclined niche audience. Commercial infrastructure has been retreating rather than growing: Namecheap, previously a major on-ramp via its Namebase marketplace, sold Namebase in January 2026 and by June 2026 had wound down Handshake TLD support on its core registrar entirely, citing the wind-down of an unnamed upstream provider. HNS traded near its 2021 peak of about $0.85 and had fallen to roughly $0.005 by mid-2026, a decline of over 99%. Rival "web3 naming" projects (Unstoppable Domains, ENS) have similarly retreated toward traditional DNS/ICANN compatibility rather than replacing it. The underlying protocol and its auction mechanism have not broken or been exploited; the market for an alternative root simply has not shown up.

Why it worked

• A real, well-specified allocation problem. Contested, unique namespace strings are a textbook setting for auction theory, and Vickrey's second-price design gives bidders a dominant strategy (bid true value) — Handshake applied a theoretically clean mechanism to a concrete resource-allocation problem rather than bolting an auction onto something arbitrary.
• Blind bidding solved the obvious griefing vector. A plain open-bid auction on a public blockchain would let competitors see and just-outbid every offer in real time; the commit-reveal blind/lockup scheme kept the true bid private until the window closed, restoring the "sealed bid" property that makes Vickrey auctions incentive-compatible in the first place.
• Burning, not extracting. Because the settlement price is destroyed rather than captured by a company or DAO treasury, Handshake avoided the credibility problem of "the auctioneer profits from higher clearing prices" — there was no principal-agent conflict to manage.
• Legitimacy-first distribution. Reserving existing brand names (with a sunrise claim period) and airdropping the bulk of supply to open-source developers, rather than pre-mining for founders/VCs, bought Handshake real goodwill in developer and free-software communities at launch, even though it did not translate into lasting mainstream usage.

Limitations and criticisms

• The auction mechanism cannot manufacture demand. A perfectly incentive-compatible way to allocate a name is worthless if almost nobody can resolve that name in an ordinary browser; Handshake solved the allocation-fairness problem it set out to solve while leaving the much harder distribution/integration problem — getting Chrome, ISPs, and registrars to actually route HNS lookups — largely unsolved.
• Namespace collision with the incumbent root is inherent, not incidental. Any name available on Handshake could also be requested, in principle, from ICANN later (or already exists as an ICANN TLD), so a "successful" Handshake auction never fully removes the legal/practical ambiguity of what a string like .market or .free actually resolves to across the wider internet.
• Blind-auction UX is a genuine barrier to broad participation. Locking up funds for a multi-day bid/reveal cycle, choosing a "blind" amount, and risking forfeiture of an un-revealed bid is far more cognitively demanding than a normal domain checkout flow — a cost the mechanism imposes on every participant to buy the collusion-resistance of sealed bidding.
• Censorship-resistance is dual-use. The same properties that make Handshake attractive for resistant, hard-to-seize naming (valued by privacy/free-speech-minded users) make it attractive infrastructure for phishing and malware domains, since none of the usual centralized DNS takedown/threat-intel tooling applies to HNS names.
• Commercial infrastructure is thinning, not thickening. The exit of Namecheap/Namebase from active Handshake support in 2026, following years of flat-to-declining price and usage, indicates the ecosystem of registrars, wallets, and resolvers needed to make the chain usable by non-technical people has not reached self-sustaining scale.

Lessons

• A cryptographically clean, incentive-compatible mechanism (blind Vickrey auctions with burns) can execute exactly as designed for years without the underlying project achieving its stated goal — auction-design correctness and product/adoption success are separable, and success on the former proves nothing about the latter.
• Replacing widely-used, deeply-integrated infrastructure (DNS root resolution baked into every browser and OS) requires winning cooperation from gatekeepers (browser vendors, OS vendors, registrars) that a protocol itself cannot auction, burn, or airdrop its way into — no mechanism design at the naming layer substitutes for that distribution problem.
• Fair-launch distribution (airdropping to open-source contributors, reserving trademarked names with a sunrise period) can earn a project real early legitimacy and goodwill, but goodwill among a technical niche does not, by itself, convert into mainstream registrar or browser support.
• Sealed-bid mechanisms that hide true bids behind an obfuscating "blind" amount are a reasonable way to approximate a private-value Vickrey auction on a public, fully-transparent ledger, but they add real UX overhead (multi-day commit-reveal, funds locked, forfeiture risk) that a centralized auctioneer with actual privacy would not need to impose.
• Infrastructure that is simultaneously censorship-resistant and unmoderated will attract both the legitimate users it was built for and abuse (phishing, malware C2) that the traditional ecosystem's takedown tooling cannot reach — a tradeoff inherent to the design, not a fixable bug.

Redesign (EDITORIAL — hypothesis, not fact)

This section is editorial hypothesis, not a description of anything Handshake did or plans. If the goal is genuinely to seed a usable alternative root rather than just a fair auction, a redesign might decouple "owning a name" from "requiring every end-user to reconfigure their resolver." Concretely: (1) ship a standardized, signed bridge format so any Handshake name owner can trustlessly publish a normal ICANN-compatible delegation (e.g., an NS record under a neutral, widely-pre-configured domain) alongside their on-chain resource record, so an HNS name resolves in stock Chrome/Safari the moment it's won, with the chain itself remaining the source of truth for who controls the bridge; this trades some purity (an intermediary NS still exists) for the actual adoption the pure design never achieved. (2) Replace the uniform weekly-release schedule with demand-signaled releases — let a deposit-and-refund "interest" mechanism, funded by refundable deposits rather than fees, surface which unclaimed strings the market actually wants next, rather than releasing tens of thousands of low-interest names on a fixed clock that mostly resulted in unused registrations. (3) Fund a resolver/extension public good (rather than relying on scattered third-party plugins) using a small, transparent, opt-in portion of burned fees redirected to resolver maintenance instead of pure destruction — accepting a modest deviation from "no protocol revenue" in exchange for durable, funded infrastructure that closes the browser-support gap. The central risk of all three changes is the same one Handshake's original designers were trying to avoid: reintroducing a trusted intermediary (bridge operator, curation signal, funded maintainer) is precisely the kind of central point of control and failure the protocol was built to eliminate, so "distribution-friendly" and "trustless" may be in permanent tension for this class of system.