The .com Pricing Lawsuit: Who Sets the Renewal Terms?

You can change the company that sends your .com renewal bill. You cannot choose a different registry for the same .com name.

The September 4, 2026 antitrust complaint against Verisign and ICANN puts that arrangement under legal scrutiny. Its allegations remain unproven. For us at Headless Domains, it raises a practical question: who sets the renewal terms once a name becomes too useful to give up?

We build on Handshake because people should be able to create namespaces and try their own ideas about how naming ought to work. That includes the economics. The protocol opens the door, and the service running each namespace still makes decisions about prices, renewal and control. We make those decisions too.

What the .com pricing complaint alleges

Jeff Kessler filed Kessler v. Verisign, Inc. et al., case 2:26-cv-09960, in the U.S. District Court for the Central District of California on September 4, 2026. The complaint alleges that agreements governing .com unlawfully protected Verisign's monopoly power and caused excessive renewal charges.

Kessler seeks a nationwide class covering people and entities that paid for .com renewals beginning September 4, 2022, requesting injunctive relief. A proposed California class covers renewal payments made while residing in California and seeks damages and other relief. Both proposed definitions have exclusions. The details are in the complaint, including paragraphs 246–247.

These are the plaintiff's allegations, not findings by a court. Our research through September 7 found no ruling on the merits or order certifying a class. The public docket snapshot reviewed was last updated September 4, so it cannot confirm later developments.

We found no case-specific public response from Verisign or ICANN in the sources reviewed. Their earlier statements explain their positions on the registry arrangement: ICANN's November 2024 renewal announcement emphasized security, stability and resilience, including new abuse-mitigation obligations. Verisign's 2025 annual report explains that its wholesale prices are contractually restricted and registrars set retail prices. Those statements predate this lawsuit.

A name becomes harder to replace the longer you use it

The annual .com wholesale registration and renewal fee is currently $10.26. Verisign has announced an increase to $10.97 on November 1, 2026. That is a $0.71 increase at the registry level; your registrar sets the final retail bill. The change was announced in April 2026, months before the complaint.

Verisign reported 166.6 million .com registrations as of June 30, 2026. That counts registrations, not active websites or individual customers. Its second-quarter domain report puts the combined .com and .net total at 179.1 million.

The current registry agreement runs through November 30, 2030, with renewal provisions. Its ordinary pricing rule allows increases of up to 7% in each of the final four pricing years of six-year cycles anchored on October 26, 2018. There are specified exceptions, notice requirements of at least six months for price increases, and registry-level options for registrations and renewals of up to ten years at the accepted price.

These contractual limits are part of the picture. Kessler is challenging the arrangements that produced them.

But shop around all you like for a registrar: the same .com name still goes through Verisign.

Imagine your agent has spent a year working with customers and other agents under one name. Payment references, discovery records and completed work all point back to it. You could buy another name for very little. Then comes the job of getting every system that knows the old one to recognize the replacement.

The renewal bill is only part of what you've committed to.

Handshake changes who can build a namespace

Handshake provides an alternative root naming system. Cryptographic keys and shared protocol rules establish control of top-level names, with DNS still part of the architecture. The Handshake FAQ explains the distinction.

A builder can acquire and operate a Handshake namespace without first obtaining a new ICANN registry agreement. They can try a different pricing model, build services around the namespace and see whether people find them useful.

That freedom to create is why open naming matters to us. Our Name What Runs manifesto explains the wider purpose. Competing namespaces give builders room to experiment. Customers still need to know who sets the terms inside the namespace they choose.

At Headless Domains, that means letting software register and renew names under its operator's authority, using prices it can read and APIs it can call. Our Agent Identity Stack guide covers the wider architecture. The prices and terms below describe the service as it stands today.

Our current prices, renewal terms and control model

Our API specification documents registration and renewal through Gems or the Machine Payments Protocol, identity resolution, and an authenticated, nonbinding registration quote. We also publish a machine-readable feed of standard annual registration and renewal prices.

We subsidize agent registrations to encourage use. As checked on September 7, our rate card lists:

Premium names can have different prices, and the Gem conversion can change. These are current rates, not a lifetime price promise. The .manifest example also shows why we publish registration and renewal separately. A subsidized agent name and a .com wholesale registration serve different purposes, so these figures aren't a like-for-like savings comparison.

We operate a service on top of Handshake. Our architecture documentation describes our combined registry and registrar, with Headless Domains maintaining the registration ownership database and SkyInclude providing DNS infrastructure. Registering a name beneath .agent is different from holding the controlling key for the .agent namespace itself.

Renewal works differently at each level. A protocol-level Handshake name needs a renewal transaction within roughly two years, costing the miner fee, as documented in the Handshake API reference. Our second-level registrations have their own service prices and terms.

Our terms explain renewal responsibility, the current 40-day expiration grace period (subject to change), and our powers to address policy violations and trademark disputes. An expired name may eventually be released or reclaimed. Human account owners remain responsible for their agents' authorized activity.

We document transfers between supported account or wallet identities. That is a transfer within our service, not a published guarantee that a registration can move to an independent registry with the same name. Native Handshake names also need compatible resolution. Our resolver guide covers public and local options; standard browsers don't resolve these names universally.

Building on Handshake does not settle every question about our service. Someone still has to look after credentials, handle recovery and keep the systems an agent relies on running.

Can an agent read the renewal rules as easily as the price?

Our price feed tells an agent what renewal costs today. Could it also check who can change that price, how much notice it gets, and which terms it accepted last year?

A machine-readable domain economics manifest could supply that context. This is a proposal for discussion, not an announced Headless Domains feature or a new guarantee.

Say your agent is due to renew. It could compare the price and policy with last year's accepted terms, check its spending authority, and flag a material change for review. That review needs to happen before expiry. Silently letting the name lapse would defeat the point.

A record could identify the renewal formula, notice period, control model and recovery policy. It could link any provider-transfer promise to the terms and procedure supporting it. Naming the root would also help agents distinguish identical spellings in different systems.

Here is a shortened example using the standard .agent rate for agent registrations observed on September 7. null marks information not established in this example. It must never be interpreted as free renewal or unlimited rights.

{
  "status": "illustrative_proposal_not_a_quote",
  "observed_on": "2026-09-07",
  "root": "handshake",
  "namespace": ".agent",
  "registration_level": "second_level",
  "pricing_scope": "standard_non_premium_agent_channel",
  "pricing": {
    "currency": "GFA_GEM",
    "period": "P1Y",
    "registration": "1.00",
    "current_renewal": "1.00",
    "future_renewal_formula": null,
    "change_authority_policy": null,
    "change_notice_days": null
  },
  "registration_operator": "Headless Domains",
  "external_provider_transfer_guarantee": null,
  "credential_recovery_policy": null,
  "native_resolution": "handshake_compatible",
  "payment_methods": ["GFA Gems", "MPP"],
  "terms_url": "https://headlessdomains.com/terms",
  "policy_version": null,
  "valid_until": null
}

Before relying on this record, an agent would need to verify the issuer, check when it takes effect and expires, and keep the exact policy version it accepted. Payment details would need current network and asset information, with service charges separated from transaction fees. Any claimed right would need support in the actual terms. A verified signature can establish that the record came from the expected issuer. It does not create the rights described inside.

The terms matter after checkout

The .com case will take its own course. We don't need to predict the outcome to have a view on who should be able to build naming infrastructure.

We want more people to be able to try, with their own ideas about ownership, pricing and what software needs from a name. Handshake gives us a place to do that. At Headless Domains, we are building a service agents can use and their operators can understand well enough to choose.

If you have an agent ready to use a name, get started with Headless Domains. Check the rates and resolution requirements, connect its records, and decide what it can spend on renewal. Give it a name with a future beyond the first transaction.