Two approaches to Handshake, and a larger question about who gets to shape the internet we use.
Namebase gives Handshake top-level domain (TLD) owners infrastructure to run registries. HeadlessDomains.com focuses on names and discovery records for agents and software services.
Consider an agent you ask to arrange dinner. It finds a table, checks a preference you mentioned weeks ago, and comes back with a booking for you to approve. You get the booking without visiting the restaurant's website.
Next Friday, you might want the same agent. You know what to ask for, and you can recommend it to someone else. The name gives you a way back.
That is a headless service at work. Software handles the requests that once needed our attention on a website.
A Larger Freedom asks what independent builders can make possible for one another. Namebase and Headless Domains offer two ways to explore that question on the same foundation.
The freedom to administer a namespace
Handshake lets a person or community acquire a top-level name and decide how to administer the names beneath it. The protocol maintains an alternative root and leaves subordinate names outside its consensus layer. Owners can develop their own registry models and applications. Handshake design notes
A community could reserve names for its members; a business could sell registrations. Someone running a service could organise its workers and public endpoints beneath a name they control.
Ordinary DNS already supports subdomains and delegation, so an operator can build an extensive service beneath example.com. Handshake lets that operator acquire authority immediately beneath its root, outside ICANN's registry-contract hierarchy. They still depend on the protocol and must maintain the name. DNS delegation; Handshake FAQ
The TLD holder decides how the namespace operates. Someone registering a name beneath it accepts the arrangements that holder has chosen.
Namebase and Headless Domains, side by side
| Main emphasis | NamebaseDomain registration and infrastructure for TLD owners to run registries. | Headless DomainsNames and discovery records for agents and services, with registration through agent workflows. |
|---|---|---|
| For TLD owners | NamebaseOwners keep their TLD keys, set SLD prices and receive buyer payments directly. Listing requires ownership verification and DNS delegation. | Headless DomainsA partner programme offers branded registrars, registry operations and migration support, subject to onboarding approval. |
| Second-level domain (SLD) registration | NamebaseA registry record under the TLD owner's delegation and policies. Selected TLDs also offer separately minted SLDs. | Headless DomainsA registration under an operated namespace, subject to renewal and registry policies. Registering an SLD does not transfer the parent TLD. |
| Information behind a name | NamebaseDNS records for websites, mail, services and other uses, including TXT, NS, DS and TLSA. | Headless DomainsDNS-linked agent.json and SKILL.md records describing declared capabilities and service endpoints. |
| Documented tools | NamebaseDomain and TLD management, DNS controls, and a self-custody wallet for HNS, auctions and on-chain names. | Headless DomainsAPI and SDK documentation, MCP integration, machine-readable guides, and registration and lookup workflows. |
| Pricing and payment model | NamebaseTLD owners set registration and renewal prices. Buyers pay owners in HNS or, where supported, Bitcoin; owners pay Namebase's fees separately. | Headless DomainsPrices vary by namespace and sales channel, with GFA Gems and machine-payment routes available. |
| Use without a website | NamebaseDNS can name services and publish records without a human-facing website. | Headless DomainsCompatible agents use API, CLI and discovery infrastructure without needing browser-native resolution. |
| Where trust comes from | NamebaseName control identifies who can change the records. Service reliability and registry policies are separate questions. | Headless DomainsIdentity and capability records help clients find a service. Clients still need to assess it and check permissions. |
Table sources: Namebase FAQ, Registry Agreement, Wallet; HeadlessDomains.com partners, terms, pricing, manifests, agent guide and authentication contract.
Namebase's July 2026 relaunch introduced a non-custodial registry. The TLD stays in its owner's wallet while Namebase supplies registry software. Owners can use the service without handing over the underlying name. Namebase's relaunch announcement
An ordinary Namebase SLD is an account-held registry record under the TLD owner's delegation. Optional perpetual SLDs are recorded on a separate blockchain, but their use still depends on the parent TLD remaining renewed and correctly delegated. SLD ownership explained; Registry Agreement, section 13
Headless Domains also operates registrations under its own renewal and registry policies. Registering yourname.agent gives you a name beneath .agent; ownership of that TLD remains with its operator. Registration terms
The freedom to choose a registration model belongs to the TLD owner. For the person buying an SLD, the question is what happens to their name if that operator changes providers or closes.
Headless, with a person still in mind
An agent choosing a gift might search six shops to find one that can deliver it. The person giving the gift still cares about the choice. They may care very little about doing the search themselves.
Over time, a useful agent could learn that you sometimes prefer the slower train, or that the restaurant everyone recommends is one you would rather avoid. Those preferences give you a reason to return beyond the list of features.
A persistent name gives you somewhere to return when the software or hosting changes. Its published destination can be updated; the systems behind it must preserve the memory and permissions that made the service useful.
HeadlessDomains.com publishes machine-readable descriptions of a service's capabilities and endpoints. DNS TXT records point compatible clients to those manifests, while the agent itself runs in the operator's chosen environment. Agent manifests
Headless Domains and SkyInclude provide API and CLI infrastructure for agents to work with these names. Browser-native resolution is only relevant when someone wants to visit through a conventional browser. HeadlessDomains.com agent overview
There is plenty of browsing people enjoy. An hour saved comparing delivery options could be an hour spent in a bookshop. That choice belongs to the person whose time was saved.
When the software behind a name changes
In the October 10 All-In episode, the speakers connect headless services with cheaper practical assistance. Around 1:25:33, one argues that software IP has become worthless. By 1:27, they are discussing agents gathering quotes without their users visiting the websites involved. All-In, 1:24–1:28
The claim about IP goes further than the discussion can support. If features become easier to reproduce, what keeps someone coming back to a particular service?
Copying an agent's features does not reproduce the experience someone has had with it. They may trust the operator to maintain it, remember their preferences and honour the permissions they have given. The name helps them find that service again.
Control over that name gives a builder room to change the software behind it while keeping the service recognisable. Handshake puts top-level naming authority within reach of independent operators. Namebase supplies registry infrastructure; Headless Domains supplies agent discovery tools. The people running the service still have to earn their customers' trust.
What Verisign proposes for agent discovery
Verisign's Efficient and Secure Discovery for AI Agents: The Case for DNS, revised September 8, 2026, examines the metadata needed to discover an agent: its protocol, capabilities, endpoint and cryptographic association. The authors draw on 119,757 unique service endpoints and 62,739 indexed MCP server entries. Under their assumptions, the estimated DNS message occupies 1,026 bytes, below the practical 1,232-byte UDP target.
That sizing result suggests useful discovery metadata can fit within practical DNS messages. The study does not measure end-to-end agent performance.
The paper cites Headless Domains' .agent offering in its future-work section, leaving an evaluation of the service for later research.
Verisign's September 1 article also proposes two DNS record types, AIDISCA and AIINDEX, for publishing agent metadata and finding where it is published.
The NANDA architecture paper takes a different approach: a lean index points to richer, verifiable agent information. Each gives software a way to find a service and learn how to connect.
Whichever discovery method an operator chooses, someone controls the name through which the service is found. Handshake gives the operator a choice about where that authority sits.
Verisign operates the .com and .net registries and has a commercial stake in conventional DNS. Its packet-size calculations are useful evidence; they leave the question of namespace ownership open. Verisign's research and company context
Traditional DNS and Handshake for agents
Handshake also uses DNS. Here, “traditional DNS” means DNS rooted in the ICANN/IANA system. The other column combines Handshake's root with Headless Domains' application tools. The first three criteria come from the Verisign paper.
| Navigational completeness | Traditional DNSCan publish endpoints and discovery metadata in compact records. | Handshake + Headless DomainsProvides agent manifests, skill descriptions and DNS pointers. Operators must supply the information clients need. | Practical assessmentEither can supply the information. Headless Domains packages it for agents; completeness depends on the published records. |
|---|---|---|---|
| Lookup complexity | Traditional DNSMetadata included in the DNS response can reduce fetches. External documents need additional requests. | Handshake + Headless DomainsThe DNS route finds a TXT pointer, then fetches a manifest. API lookup is another route through the provider's service. | Practical assessmentRequest counts depend on where metadata is stored, what is cached and how validation works. |
| Transaction performance | Traditional DNSWidely deployed resolution and caching. | Handshake + Headless DomainsLocal or hosted resolution and DNS caching are available. Manifest hosting and validation add their own costs. | Practical assessmentA performance comparison needs measured latency, failures and record freshness under the same workload. |
| Sovereignty and autonomy | Traditional DNSSubstantial control within a delegated domain, subject to the parent registry and registrar arrangements. | Handshake + Headless DomainsA self-custodied TLD gives control of the branch beneath the Handshake root. An SLD buyer still depends on its TLD operator. | Practical assessmentHandshake changes top-level authority. Agent automation is possible with either naming system. |
| Permissionless entry at the top level | Traditional DNSOperating a new public generic TLD follows ICANN's application and delegation process. | Handshake + Headless DomainsAvailable names can be acquired under Handshake's auction rules without an ICANN application. Existing, reserved and unavailable names are distinct cases. | Practical assessmentHandshake opens TLD ownership to participants under its auction and protocol rules. |
| Use by software agents | Traditional DNSAgents use standard DNS libraries, APIs and service protocols; a website is optional. | Handshake + Headless DomainsAgents use compatible resolvers or the Headless Domains/SkyInclude API and CLI infrastructure; browser-native support is unnecessary. | Practical assessmentBoth support use without a browser. The client must use the intended namespace and validate the relevant records. |
Sources: Verisign paper, sections III–V, ICANN application and delegation process, DNS delegation and caching, Handshake FAQ, hnsd architecture, resolver guide and HeadlessDomains.com interfaces.
To use a service, an agent needs its address, connection requirements and a description of what it offers, along with a way to authenticate the relevant records.
| Endpoint or location | Traditional DNS with supporting softwareAddress records and service bindings locate services; external metadata can supply full URLs. | Handshake + Headless DomainsDNS records and configured manifest pointers locate services. The operator must publish a working endpoint. |
|---|---|---|
| Capability awareness | Traditional DNS with supporting softwareTXT pointers or application-specific records can lead to capability descriptions. | Handshake + Headless Domainsagent.json and SKILL.md describe what the operator says the service can do; clients must assess those claims. |
| Protocol awareness | Traditional DNS with supporting softwareService-binding parameters and application metadata identify connection requirements. Proposed agent records add explicit protocol information. | Handshake + Headless DomainsManifest protocol and workflow fields describe supported interfaces; clients must implement the relevant protocol. |
| Authenticity and integrity | Traditional DNS with supporting softwareValidated DNSSEC authenticates DNS data. DANE/TLSA can bind a service to its certificate or key. | Handshake + Headless DomainsHandshake proofs authenticate root-level name data; DNSSEC can extend validation through delegated zones. Compatible clients can validate TLSA bindings. |
| Trust model and limits | Traditional DNS with supporting softwareA configured DNSSEC trust anchor and delegation chain, plus the application's authentication and permission checks. | Handshake + Headless DomainsHandshake consensus and name-control keys, delegated DNS, and any chosen registry or API provider. Current public records do not independently verify a human operator or agent safety. |
Sources: SVCB and HTTPS records, DNSSEC, DANE/TLSA, Handshake design, manifest schema and assurance limits, and native HTTPS validation.
Permissions belong to the relationship
A record can tell an agent where to connect. Permission to act must come from the service receiving the request.
Headless Domains' integration guide describes linking a domain to an Agent Relationship Protocol (ARP) identity. ARP defines agreed scopes and policies that are checked on requests. With AgentID Connect, an owner can approve a relationship and set its permissions, then review activity or revoke access. ARP integration; ARP scopes and policies; AgentID Connect
ARP relationship permissions are separate from HeadlessDomains.com's ordinary API keys, which currently have no selectable, enforced per-key scopes. Applications still need to check what each request is allowed to do. Authentication capabilities and limits
A translator or researcher could use these components to offer a specialist service on their own terms. Other systems could call on that work without employing the person who provides it.
An operator can organise services beneath a TLD and let an agent administer records using limited credentials. Keeping the ownership keys separate limits what the agent can change. Network isolation and the agent's intelligence come from the systems behind the name.
For local resolution, hnsd combines a lightweight Handshake client, proof retrieval and DNS-serving components. It reduces reliance on a hosted recursive resolver while still using network peers and authoritative DNS infrastructure.
For secure transport, the native Handshake HTTPS guide describes checking a server's certificate against authenticated TLSA records. A client must perform that validation in addition to resolving the name, whether it runs on Omarchy or another operating system.
What builders can make possible for one another
A builder who wants to run a Handshake registry can use Namebase while keeping the TLD keys and setting registration prices. Someone giving an agent a discoverable name can use Headless Domains' records and API workflows.
A TLD owner could use both. With suitable records and integration work, a namespace administered through one provider could support services discovered through another. Customer records still need a migration path between providers.
The test comes when a transfer fails or a hosting company closes. Shared record formats and people willing to handle the migration can keep a service available through those changes.
The next builder may want to offer something neither company anticipated. Handshake lets them acquire a namespace and administer it on their own terms, while working alongside people who have chosen different tools.
For the person arranging dinner, most of that machinery can stay out of sight. They remember that the agent understood what they wanted, and they know what name to ask for next Friday.