Every UCP capability, transport, and payment handler has a name that looks like this: dev.ucp.shopping.checkout. That dotted, backwards-looking string is a namespace — the quiet convention that lets the protocol grow without a gatekeeper. And in mid-June, a proposed spec change set out to pin down the rule for who is allowed to use one.

Here's how UCP namespaces work, why they're written backwards, and what a proposed change opened on June 19 would tighten.

#The 30-second version

• UCP names everything — capabilities, transports, payment handlers — with reverse-DNS namespaces, e.g. dev.ucp.shopping.checkout.
• The leading part is a domain spelled backwards: ucp.dev becomes dev.ucp.
• Controlling the domain is what entitles you to publish names under it. No central registry, no approval queue.
• A proposed spec change (PR #530, opened June 19) would make that rule enforceable: a namespace would have to prove it's bound to the domain it claims.

#Why reverse-DNS at all

The reverse-domain convention is borrowed from decades of software practice — Java packages, Android app IDs, Apple's UTIs all use it for the same reason: it produces globally unique names without anyone having to hand them out. If you control ucp.dev, every name under dev.ucp.* is yours; if you control shopify.dev, dev.shopify.* is yours. Two parties can never accidentally mint the same capability name, because the namespace is rooted in a domain only one of them owns.

That matters for UCP specifically because the protocol was designed for discovery without a central registry — the same "boring core, no blueprint" philosophy Tobi Lütke and Ilya Grigorik described and we wrote about here. Anyone can define a new capability and ship it tomorrow, as long as they define it under a domain they control. Namespaces are how UCP stays open and collision-free at the same time.

#Anatomy of a UCP namespace

Take the most common one in the wild:

dev.ucp.shopping.checkout
└─────┘ └──────┘ └──────┘
authority  group  capability
(ucp.dev)

• dev.ucp — the authority: ucp.dev reversed. This is the canonical core-protocol namespace, where the official shopping capabilities live.
• shopping — the capability group.
• checkout — the capability itself.

Not everything lives under dev.ucp. Anyone extending the protocol declares under their reversed domain:

#What actually appears across 10,000 stores

The shape of namespace adoption is the story we've tracked all year. The core dev.ucp.shopping.* bundle is near-universal; the deep extensions are a rounding error.

Two things stand out. First, almost everything in production lives in the canonical dev.ucp.* namespace — third-party and merchant-owned namespaces are vanishingly rare, because the overwhelming majority of verified manifests today are Shopify-served, declaring the standard bundle. Second, new protocol surface area always arrives as new names under that authority — which is exactly why watching which namespaces show up in the crawl is how we measure the protocol maturing past "agent-shoppable".

#Who can claim a namespace? (what PR #530 proposes)

Today the spec says schema URLs must match the namespace authority — but it never defined how to compute that authority, so no implementation could enforce it consistently. PR #530, open as of late June, proposes a normative algorithm:

1. Parse the capability's schema URL — require HTTPS, reject embedded credentials.
2. Verify the host is a real registered domain (at least two labels, no raw IPs).
3. Reverse the host labels into an authority prefix.
4. Require the namespace name to begin with that prefix plus a dot — so a dev.ucp.* name must be served from a schema URL on ucp.dev.

In the PR's own framing: "Binding proves the name is controlled by the domain owner — whether to negotiate/support a capability is the client's decision." Only the machine-fetched schema URL is authority-bound; the human-readable spec doc can live anywhere.

The same PR would also broaden the reverse-domain grammar to accept real-world domains the current regex rejects — interior hyphens (example-shop.com → com.example-shop.*), digit-leading labels (3m.com → com.3m.*), and internationalized punycode TLDs.

#Why this is the foundation, not a footnote

A namespace you can't squat is the entire point. Authority binding is what separates "this capability is defined by whoever controls ucp.dev" from "anyone can publish dev.ucp.shopping.payment and agents will trust it." It's the provenance principle applied to names — the same idea behind UCP message signatures, where a request has to prove who sent it. Names and requests both have to be accountable to a domain.

#What this means if you're shipping UCP

• If you only declare the Shopify-bundled capabilities, you never mint a namespace — you consume dev.ucp.*. Nothing to do.
• If you hand-build or extend the protocol, declare your capability under your own reversed domain and serve its schema from that domain over HTTPS. Don't publish under dev.ucp.* — you don't control ucp.dev, and if #530 lands, a validator can prove it.
• Validators can check the binding. A capability whose schema host doesn't reverse to its namespace prefix is exactly the kind of mismatch a conformance check should flag — run a UCP Score to see how your manifest reads.

Namespaces are the unglamorous machinery underneath everything else in UCP — the reason a fulfillment broker, an ask capability, and an AP2 mandate can all be added next month without a committee handing out IDs. They just show up as new names under a domain that's allowed to mint them.

#About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and — through UCP Playground — test how real AI agents behave against real stores. Namespace authority binding is exactly the kind of provenance rule a conformance check exists to enforce.

• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• Browse the directory: ucpchecker.com/directory
• Get notified on changes: ucpchecker.com/alerts

#Sources

• The change: PR #530 — define namespace authority binding + broaden RDNS grammar
• Capability adoption is from the UCP Checker crawler as of June 2026; see the June ecosystem report and live stats.
• Related: UCP Message Signatures (RFC 9421) · Protocol Design and the Validation Layer
• Run a check: ucpchecker.com/score · browse the directory