Handshake Explained: How Decentralized DNS Works in 2026

Handshake is a blockchain-based naming protocol. Its goal is to replace the single, centrally coordinated root of the Domain Name System with a root zone that anyone can verify. It launched in 2020, and research papers and project documentation describe it as a decentralized, permissionless system in which peers authenticate and help manage the root of a naming system.

The key idea is small but significant. Today every domain ending, such as.com or.org, is a top-level domain (TLD) listed in a root zone that one coordinated process maintains. Handshake puts that root zone on a blockchain. Anyone can bid for a TLD that is not already reserved, and ownership is recorded on a ledger that every full node checks for itself.

A few points frame everything else in this guide:

• It is an alternative root, not a replacement. The conventional DNS keeps working. Handshake names sit beside it and need compatible software to resolve.
• The unit being sold is the TLD. A Handshake name is a top-level name, so the owner can create subdomains under it, similar to how a registry runs a TLD.
• HNS is the native coin. It pays for auctions and transaction fees and rewards miners who secure the chain.
• Security is built around DNSSEC. The project says authenticity is enforced by default instead of being optional.

Handshake is infrastructure, not a DeFi app. There is no yield, lending or trading product built into the naming layer itself, so it suits readers curious about how the web's addressing could work, not those looking for a financial protocol.

To see why Handshake exists, it helps to know how a normal lookup works. When you type a web address, your device asks a recursive resolver, usually run by your internet provider or a public DNS service. If the resolver does not already know the answer, it asks a root server, which points it to the servers for the relevant TLD, which in turn point to the servers for the specific domain.

The hierarchy has three layers where control concentrates:

• The root zone. One coordinated process decides which TLDs exist and who operates them.
• TLD registries. Each registry controls the names under its TLD and can suspend or transfer them under its own policies and local law.
• Registrars and resolvers. Companies sell domains and answer lookups, and users generally trust whatever answers they receive.

This design has worked at enormous scale, but it carries known weaknesses. A domain can be seized or suspended by an intermediary. A resolver can be forced to block or alter answers. Unsigned records can be spoofed. Handshake's pitch targets the first layer: if the root itself is a public ledger, no single party decides which TLDs exist or who owns them.

It does not remove every dependency. Registrars, hosting, certificate handling and the resolvers people actually use remain separate decisions. Commentary on the project makes this point directly: Handshake decentralizes the root, but much of what sits below the root still depends on whatever infrastructure a name owner chooses.

Handshake is a UTXO-based blockchain, with a design that will look familiar to anyone who knows Bitcoin. Miners secure it with proof of work, and each block can include ordinary coin transfers alongside naming transactions such as opening an auction, placing a bid, revealing a bid, registering records and renewing a name.

Two design choices matter most for DNS:

• Light verification. The chain commits to the state of all names in a compact data structure, so lightweight clients can verify a specific name's records with a short proof. They do not have to download the whole chain. This is what makes it practical for a resolver on a laptop or phone to check answers for itself.
• Root zone as chain state. The set of TLDs, their owners and their records are derived from the chain. Every full node holds the same view, so there is no root server to trust.

The records an owner publishes are standard DNS-style data. An owner can point a name at name servers, publish address records, or store DNSSEC keys, so existing DNS software and concepts carry over. The project has also described using the chain for certificate-related purposes, since a name's owner can publish keys that clients check against the ledger.

On launch, the project allocated a large share of the initial supply as a free airdrop to open-source developers and to other recipients, and reserved existing TLDs and popular domain names so their legitimate owners could claim them later. Supply details and emission schedules are documented by the project, so check the current documentation instead of relying on summaries.

Handshake sells names by auction, not through a registrar. The design is a blind, second-price (Vickrey-style) auction, which is meant to make honest bidding the best strategy and to prevent sniping.

The process runs in stages:

1. Open. Anyone can start an auction for a name that is not reserved or already owned. A short delay follows before bidding begins.
2. Bidding. Over several days, each bidder submits a sealed bid. The bid carries a lockup amount that hides the true bid, so rivals cannot see how much anyone is willing to pay. Bidders can lock more than they bid to disguise their intent.
3. Reveal. In a following window, bidders reveal their real bids. A bid that is not revealed is forfeited.
4. Close. The highest revealed bidder wins but pays the second-highest bid. The rest of the lockup returns to the winner, and losing bidders recover their funds.

The price paid by the winner is burned instead of going to a registrar or registry. After winning, the owner registers records and must renew the name periodically, roughly every couple of years, by sending a renewal transaction. A name that is not renewed can lapse and be reopened for auction.

Because timing windows are measured in blocks, exact durations are approximate, and parameters are defined in the protocol rules. Check the current specification before you plan around any deadline. Also remember that bid amounts, once revealed and locked, are committed in HNS, whose market price moves, so the real-world cost of a name changes over time.

Resolving a Handshake name takes more than typing it into a stock browser. The standard DNS root does not list these names, so a resolver must know about the Handshake chain. There are a few common routes.

• Run your own light client or full node. Handshake software includes a full node and a lightweight resolver that verifies answers using chain proofs. This is the most trust-minimizing option because your device checks the data itself.
• Use a DNS service that supports Handshake. Some privacy-focused DNS providers added Handshake support, so queries to a supported resolver can return answers for these names. You then trust that provider's resolver to be honest.
• Use a browser extension or gateway. Some tools and web gateways translate Handshake names for ordinary browsers. Convenient, but you are relying on whoever operates the gateway.
• Use wallet or marketplace tools. Services where people buy and manage names often provide ways to preview or open them.

A common question is who controls the servers that answer Handshake lookups. There is no single server or fixed address. Any node or resolver that follows the protocol can answer, and the quality of the setup depends on which one you pick. If you choose a hosted resolver, you gain convenience but give up some of the verification that makes the system interesting.

Secure web access to a Handshake site also needs a valid certificate arrangement, which can be an obstacle for visitors who have not configured their devices. Test any site you plan to rely on from a clean device before you depend on it.

Because Handshake sells TLDs, its uses differ from buying a single domain under.com. The practical options fall into a few groups.

• Owning a TLD. A holder can issue subdomains to others, run a community namespace, or keep the name for a personal brand. This is closer to running a small registry than owning a website address.
• Censorship-resistant websites. A site pointed at a Handshake name cannot be removed by a registry decision, though hosting and any gateway still remain points of failure.
• Wallet and payment names. Owners can publish addresses or other records, so a name can act as a readable identifier. Support for this depends on the apps involved.
• Experimental identity and email. Some builders explore using a name's keys for sign-in or certificate-style proofs, which is early-stage and unevenly supported.
• Speculation. Some people buy short or attractive names hoping to resell. This is a market with uncertain demand and is not an income source.

Be realistic about adoption. A site on a Handshake name is reachable only by people whose software understands it, which limits audience size. A public project page, a developer tool, or an experiment is a more natural fit than a business that depends on mainstream traffic.

Compare what you need before you bid. If your priority is reaching ordinary visitors, a conventional domain remains simpler. If your priority is control that no registry can override, Handshake offers something conventional DNS does not, with the trade-offs described in the sections below.

Handshake decentralizes ownership of the root zone. That is a real contribution: every peer can validate the chain, and no single entity controls who holds a TLD. But it is worth being precise about what that does and does not cover.

Where it is decentralized

• Ownership records are public and checked by every full node.
• Names cannot be seized by changing a registry database, only by the owner losing keys.
• Anyone can run a node or resolver.

Where decentralization is limited

• Resolution in practice. Most users reach Handshake names through a hosted resolver or gateway, which reintroduces trust in an operator.
• Everything below the root. Name servers, hosting, certificates and email are still chosen by the owner, and most are conventional centralized services.
• Mining and holdings. Proof-of-work chains can concentrate hash power, and token distribution affects influence. Review current data from independent sources.
• Marketplaces. Many people buy and manage names through a few companies, which may hold keys on a user's behalf.
• Compatibility. Without default support in browsers and operating systems, usage depends on opt-in tools.

Academic work on blockchain-based DNS has looked at Handshake as a way to offer an alternative and extended system by managing the root on a blockchain. That research describes the design and its records, and does not claim the system is a drop-in replacement for the existing one.

A fair summary is that Handshake gives a decentralized foundation and leaves the rest of the stack to each owner. How far you carry that decentralization depends on the choices you make.

A naming system is only as safe as the keys and habits around it. These are the main risks and practical defenses.

Key management

• Whoever holds the private keys controls the name. Losing them can mean losing the name permanently, and nobody can reset access for you.
• Store a seed phrase offline, never in a screenshot, email or cloud note, and never type it into a website or share it with anyone offering support.
• If you use a marketplace that holds names in custody, understand that you rely on its security and policies. Consider moving valuable names to a wallet you control.

Renewals

• Names must be renewed periodically. Set reminders well ahead of the deadline, and check the current renewal window in the protocol documentation.

Phishing and look-alikes

• Names can resemble well-known brands or other owners' names. Check spelling carefully before sending funds or entering credentials.
• Treat unsolicited messages about an auction, a transfer or a wallet problem as suspicious.

Resolver and gateway trust

• A resolver can return wrong answers if it is compromised or malicious. DNSSEC validation and running your own light client reduce this risk.

Financial risk

• HNS is a volatile asset. Do not spend money you cannot afford to lose, and check live market data before you bid, since the cost of a name in everyday currency changes constantly.
• Buy HNS only through venues you have reviewed, and confirm whether your local rules allow it.

None of this is unique to Handshake, but the stakes are real because a name often underpins a website or identity that others rely on.

Handshake is often compared with other blockchain naming systems, most often Ethereum Name Service (ENS). They solve related problems at different layers.

Feature	Handshake	ENS
Layer	Its own blockchain and root zone	Smart contracts on Ethereum
What you buy	A top-level name	A name under.eth and some DNS names
Main use	Alternative DNS root	Readable wallet and app identity
Consensus	Proof of work	Ethereum's validators
Resolution	Needs Handshake-aware resolvers	Supported by many wallets and apps
Payment	HNS	ETH

The main difference is scope. Handshake tries to replace the root of a naming hierarchy with a new one. ENS works inside Ethereum's existing ecosystem and is mainly used to map readable names to addresses and other data. Wallet support is wider for ENS, while Handshake targets the DNS stack itself.

Other projects take their own approaches, including name systems on other chains. Details and features change, so check each project's documentation before choosing one.

Choosing between them depends on the goal. For a human-readable wallet name in Ethereum apps, ENS usually fits. For a TLD that sits in an independent root and can be used with DNS-style software, Handshake is the closer match. For a website that must be reachable by everyone, a conventional domain is still the most practical choice.

If you want to explore Handshake, a cautious order of steps keeps risk low.

1. Read the documentation first. Learn the auction stages, renewal rules and record types from the project's own materials before spending anything.
2. Try resolution before buying. Set up a Handshake-aware resolver or a supported DNS service and visit existing names. This shows how reachable these names really are for your audience.
3. Set up a wallet you control. Use official wallet software, record the seed phrase offline and test a small transfer before larger ones.
4. Get HNS through a venue you have vetted. Availability on exchanges changes, so check current listings and your local rules, and be aware that exchange accounts typically require identity checks. Consider the fees and the withdrawal process.
5. Practice with a low-value name. Walk through bid, reveal and registration on a name you would not mind losing, so you understand the timing.
6. Plan renewals and backups. Add calendar reminders and keep a recovery plan.

For readers who want to understand how on-chain tools work beyond naming, the same habits apply across crypto: use self-custody where you can, verify contracts and addresses, and avoid funds you cannot afford to lose. Decentralized exchanges such as Uniswap V4 handle token swaps, lending markets such as Aave V3 handle borrowing and earning, and liquid staking such as Lido handles Ethereum staking. These are separate products with their own risks and say nothing about Handshake's merits.

Crypto trading and speculation are not suitable for everyone and may be restricted where you live. Check local rules and only participate if you are of legal age.