Unstoppable Dropped Its ICANN .agent Plan. Handshake Already Has a Root

Unstoppable filed five top-level domains with ICANN and did not proceed with .agent or nine of its own Web3 strings. The interesting part is not who “won.” It is the reason they gave—and what that reason says about the difference between selling blockchain names and operating a root.

On 25 August, Unstoppable published two lists. The first covered the strings it submitted in ICANN's 2026 new-gTLD round: .agi, .robot, .gram, .hub, and .xmr. The second covered the strings that were not going forward.

That second group included partner projects such as .privacy, .brave, .anime, .agent, and .twin. It also included nine Unstoppable strings: .crypto, .wallet, .polygon, .nft, .bitcoin, .dao, .unstoppable, .zil, and .blockchain.

Then came the sentence Handshake people should read carefully.

“For us, that means 4M+ existing Web3 names … who … never asked to be in the DNS.”

Unstoppable's full explanation is that ICANN's planned integration rules would require names in an integrated namespace to be registered in DNS, paid for, and connected to registrant-data disclosure. Unstoppable said it would not force that conversion or bill on people who bought an on-chain name for a different purpose.

I think that is a fair decision for those customers. It is also the clearest explanation yet of why Handshake people kept insisting that Unstoppable never had a root.

A naming product is not automatically a root

DNS starts with a root zone: the list of top-level domains and the information needed to find their nameservers.

Handshake put that root-zone ownership on a blockchain. A Handshake TLD owner can publish DNS delegation records and operate a registry below that TLD. Existing ICANN names such as .com were reserved at launch, so an HNS-aware resolver can keep using the conventional internet while also seeing Handshake names.

That does not make Handshake easy to distribute. It still needs an HNS-aware resolver, browser, DNS endpoint, or gateway. But the root exists. The TLD exists in that root. The delegation uses DNS.

Unstoppable took a different route. It sold second-level labels in company-managed blockchain namespaces and made them useful through its own integrations and software. Those labels could be valuable for payments, profiles, wallets, or identity. They still were not entries in the IANA root or the Handshake root.

The ICANN application was the path that might have turned selected strings into conventional DNS TLDs. Once the technical proposal required more than four million historical names to fit DNS registration, payment, and registrant-data rules, the mismatch became expensive and uncomfortable.

Handshake does not need to retrofit its TLDs into being a root. It started there.

.agent is the clean live example

Unstoppable and Sentient had announced an intention to apply for ICANN .agent.  (post was removed, backed up here and on wayback here. Unstoppable now lists that partner string among the applications not proceeding.

Meanwhile, .agent already exists as a TLD on Handshake. It can be resolved with HNS-aware software, used with DNS records, and connected to agent manifests and services. That is what “live” means here. It does not mean the name works in stock Chrome or Safari with default DNS.

There is another important qualifier: Unstoppable dropping its plan does not mean nobody applied for .agent. Agent Community, operated by Open Agent Registry, says it submitted a community application to ICANN. Its proposed .agent does not exist in the IANA root today. ICANN's official application reveal will establish the full contention set.

So this is not a victory claim over the ICANN process. The honest claim is narrower: Handshake .agent was first, is live in the Handshake root, and did not need ICANN to create it.

Agents do not have to wait for Chrome

For a human typing a name into an untouched browser, the default path still matters enormously. If ICANN later delegates the same string, stock browsers will follow the IANA root. A same-label collision can send two people to different destinations depending on their resolver.

We should never hide that.

But the agentic web changes the distribution question. An agent is software. Its operator can give it a DNS-over-HTTPS endpoint, a resolver library, a gateway policy, or a browser that understands Handshake. It can discover a service, retrieve a machine-readable manifest, check a key, and follow an explicit trust policy without waiting for Google or Apple to change a consumer default.

That does not make collisions disappear. It makes them less decisive for traffic that was never going to depend on a human typing into default Chrome.

The next internet user may be a process looking for a named service, not a person looking for a homepage. For that user, resolver configuration is part of the runtime. A Handshake name can be useful wherever that runtime intentionally supports the root.

This is not a dunk on Unstoppable

Unstoppable is offering a refund path to eligible customers for named strings it did not take forward. People who bought those names should read the company's terms and make their own decision. They did not ask to become props in somebody else's root war.

This announcement also does not mean dual-root questions are over. Other 2026 applicants are pursuing strings that already exist on Handshake. It does not mean Handshake won ICANN; Handshake did not apply. And it does not mean Unstoppable is dead.

It means the architecture mattered.

If a system begins as a company directory of blockchain labels, turning it into a global DNS registry later is not a checkbox. If a system begins as a root zone that delegates into DNS, it still has a distribution problem—but it is already a root.

What the Handshake community should do now

First, make names resolve. Give users and agents honest, maintained paths instead of promises about future browser support.

Second, operate real TLDs. Publish useful sites and machine-readable services. A root earns attention when something worth reaching lives inside it.

Third, participate in the standards discussion. ICANN is accepting comments on its initial report about integrating gTLDs with alternative naming systems until 21 September 2026 at 23:59 UTC. Handshake name owners and resolver builders should explain what already exists, how control works, and where a “same name, same controller” assumption does or does not fit a permissionless root.

For transparency, I am commercially involved with HeadlessDomains and the Handshake .agent namespace. My view is not neutral: I want Handshake names to become useful infrastructure for agents. That is also why I want the claim to stay honest.

If you want to try the root instead of debating it, download SkyInclude Browser and open a Handshake name. Then read the ICANN TSG proceeding and submit a short, technical comment before 21 September.

For the agentic web, what matters more: reaching the default browser, or giving software an open root it can intentionally resolve today?