State of UCP · Q3 2026

The State of UCP, Q3 2026

The most-endorsed protocol in commerce — how much is actually deployed? A tracker we plan to refresh monthly.

We were curious how much of UCP is genuinely deployed versus endorsed, so we set out to measure it layer by layer — and we plan to keep measuring, on a monthly cadence, in the open. This is the opening edition: an independent, unofficial, data-backed read (not affiliated with or endorsed by the UCP maintainers), with the data as of 2026-07-17. Each number links to its exact source — the spec line it was counted from, the primary announcement, or the raw data we measured (published alongside this page) — and where the honest answer is "announced, not verifiably live," we say so. We are certainly missing things and would rather be corrected than confident: if you build on UCP and see it differently, please tell us. No individual merchant is named or graded.

A note on honesty. This is a best-effort, independent read, and we would rather be corrected than confident. We measured what we could and linked each figure to a source — but measurements have limits, methods can miss things, and even primary sources can be wrong or change over time. If anything here looks off — a number, a link, a claim — please tell us and we will check it and fix it, and note the correction. Getting it right matters more to us than looking right — help us keep it honest.

1 · The ambition: compounding fast, with nearly every major name behind it

The Universal Commerce Protocol — Google and Shopify's standard for agent-driven shopping — arrived in January 2026 with co-developers Shopify, Etsy, Wayfair, Target and Walmart, and twenty-plus endorsers including Adyen, American Express, Best Buy, Flipkart, Macy's, Mastercard, Stripe, The Home Depot, Visa and Zalando (Google's launch post, Shopify Engineering). Its payments companion AP2 launched with Mastercard, Amex, JCB, UnionPay, Adyen, PayPal, Coinbase and more (Google Cloud, Sept 2025).

The spec has moved as fast as the endorsements. Across three tagged releases, the count of MUST-level requirements in our register went from 178 to 188 to 364 — nearly doubling in the latest release. Every requirement is individually traceable at spck.dev/checks, each linking to the exact spec line it comes from.

Precision note: the artifact tagged v2026-04-08 was finalized in a commit dated 2026-05-22 after post-date cherry-picks — "three releases in three months" describes the tagged artifacts, not a clean calendar cut.

AreaJan 11Jan 23Apr 08What it is
identity-linking0057OAuth account linking for agents
signatures0033RFC 9421 request/response signing
catalog0032Product search & lookup
error model0025In-band structured errors
cart0014Pre-checkout cart management
totals0014Money-math reconciliation rules
payment353744incl. the AP2 mandate extension

Identity, cryptographic signatures and agent payments all arrived essentially at once: UCP stopped being a checkout API and became a security-and-identity protocol. One hazard for anyone maintaining an implementation across versions: requirement IDs are renumbered between eras, so pinning by ID can silently change meaning.

That is the ambition. The rest of this page measures what has actually been deployed underneath it — layer by layer, because endorsement is not adoption.

Update (late July 2026): the pace has not slowed. The spec's main branch has already moved well beyond the 2026-04-08 tag, with a substantial next release taking shape — buyer consent, split payments, a loyalty extension, delegated identity providers, fulfillment methods on the catalog, and new permalink, policies and Actions primitives have merged to main. In the same window the open-source reference server caught up to the 2026-04-08 release (its /.well-known/ucp now advertises that version, where earlier it served 2026-01-23) — a reminder that even the canonical implementation trails the written spec by a release. The gap this page is about is not closing; the spec keeps opening new frontier ahead of the deployment underneath it.

2 · The buyers: essentially one, so far

An agent protocol needs agents that buy. No agent surface beyond Google's own is confirmed by a primary source to consume UCP — AI Mode in Search, the Gemini app, and Business Agent (Google). That same announcement frames the shopping side as still arriving — UCP "will soon power a new checkout feature" in AI Mode and the Gemini app — rather than generally available at launch. Claims that other AI assistants consume UCP appear only in secondary marketing blogs; we found no primary source, so we don't report them as fact.

3 · The sellers: one platform's provisioning, and a handful of real adopters

We probed the /.well-known/ucp endpoint of 8 named launch partners directly. None served a real UCP profile — every one returned a 404, a redirect, or a bot wall. That is not a failing: by design, these brands participate through Google's managed agent surfaces rather than hosting their own endpoints. It is a subtle point worth flagging, because it means the marquee names cannot be counted as live UCP endpoints — and many public tallies still count them.

The endpoints that do exist are overwhelmingly one platform's automatic provisioning. Population frame: the UCPChecker/ucp-merchants dataset (CC-BY-4.0); measurement: our own read-only probe on 2026-07-17, aggregates published in scan-summary.json.

3037
verified domains probed
2974
served a live, valid profile
99.4%
route to a single platform's infrastructure (*.myshopify.com)
11
deliberate, self-hosted endpoints

Two independent registries agree with the hosting picture: the ucpregistry.com API lists 47 verified merchants — all on the same platform — and the community awesomeucp directory resolves the same way. This is one platform switching on UCP across its storefront base: infrastructure readiness at scale, on the platform's timeline, not thousands of independent adoption decisions. And it says nothing about live agent transactions — no primary source anywhere quantifies those, so neither do we.

Strip the platform default away and genuine, self-directed adoption is tiny — roughly a handful of real self-hosted merchants, a few ecosystem tools, and a few demos, including one booking-and-scheduling vendor extending UCP beyond retail with custom capabilities. Here is the striking part: the advanced, per-merchant features of the spec live almost exclusively in that tiny deliberate tail.

The spec's frontierEndpoints advertising it
RFC 9421 signing keys published11 (0.4%)
identity-linking capability4
buyer-consent capability4
AP2 payment mandates2

The 99.4% of endpoints on the platform default carry none of the frontier; the handful who deliberately adopted carry essentially all of it — one self-hosted retailer implements the entire stack, AP2 payment mandates included, by itself. The spec's January ambition is running years ahead of any real, differentiated deployment.

4 · The developers: enormous interest, early implementation

The gap shows up a third time in the code. The UCP spec repository has 3216 stars — remarkable for a six-month-old protocol. The repositories you'd actually build on are far smaller: samples 225, python-sdk 80, js-sdk 45, conformance 21 stars (captured 2026-07-17). Downstream use is smaller still — the Python SDK shows roughly 7 dependent repositories, and a code search for the AP2 mandate token returns single digits across all of GitHub.

SDK downloads are modest but real, consistent with a young protocol: the official @ucp-js/sdk sees about 9239 downloads/month, the official Python ucp-sdk about 2916/month, and the Rust ucp-schema about 1979 lifetime. Beyond the official org, roughly three dozen third-party repositories genuinely implement UCP — platform connectors, a community Java SDK, vendor demos: a real implementer base, but an early one.

5 · The payments frontier is announced, not live

AP2's card-network cohort is the deepest endorsement list of all — and the least deployed. In the primary announcements, no card network is live for agentic card payments; AP2's launch framed itself as a call for collaboration. The only production claim in the AP2 world is the x402 crypto extension (Google Cloud) — crypto rails, not cards. That matches what we measured in the wild: 2 live endpoints advertise AP2 mandates, and the mandate token barely appears in public code at all.

6 · Why the "how many merchants?" question is so easy to get wrong

  1. A served discovery profile is not an adoption. Some 99.4% of "verified UCP merchants" are one platform auto-provisioning an endpoint; the store made no decision. Provisioned ≠ adopted ≠ transacting.
  2. An endorsement is not a deployment. The marquee brands endorse and participate via managed surfaces; they do not serve their own endpoints.
  3. "Conformant" is three different questions. Of the 364 requirements, as we classify them: 185 test a business server, 90 bind the buying agent (which almost no tooling measures — our dedicated agent-side register catalogues 105 platform obligations, public at agent-coverage.json), and 89 are process/manual. The failures that will actually hurt users — an agent completing a checkout whose totals don't reconcile, or paying with an instrument the merchant never offered — live on the agent side, measured today by almost no one.

7 · Seven things worth checking in your own implementation

  1. Discount signs. In 2026-04-08, discount amounts in totals[] are negative (schema-enforced) — the opposite of the earlier convention, and the most common money-math bug.
  2. Signature encoding. RFC 9421 requires fixed-width raw r‖s; most crypto libraries emit ASN.1/DER by default. The 30-second check: base64-decode one signature — a conformant P-256 signature is exactly 64 bytes.
  3. The error model. UCP's canonical failure posture is in-band (HTTP 200 with a messages[] entry of type error), not HTTP-4xx-only — implementations still disagree here.
  4. Serialization strictness. Null-padding unset optional fields, or generated models that don't enforce minProperties, quietly produce non-conformant payloads.
  5. Transport parity. What your profile advertises vs. what each transport actually serves, and header requirements that differ between REST and MCP.
  6. The AP2 payments frontier. The mandate layer tracks an evolving draft; wire format, schema pattern and reference implementation can disagree. Pin exact versions and validate against more than one oracle.
  7. Toolchain drift. Published package versions can lag tagged releases — verify what your dependencies actually resolve to.

Several of these are already converging in the reference implementations as the ecosystem matures — so check against the current release, not an older snapshot.

8 · What to watch

The through-line is a protocol whose ambition and endorsement are running well ahead of its deployment. What would close the gap: a second buyer-agent ecosystem beyond Google's surfaces; a card network going live on AP2; non-platform merchants adopting the frontier features at any scale; and agent-side conformance becoming table stakes the moment real money moves through autonomous agents. The distance between "passes conformance" and "behaves safely" — and between "endorsed" and "deployed" — is where the next year of this ecosystem gets decided. We will keep tracking it here month by month, and we would genuinely welcome the help: if you are building on UCP and seeing something different from what we measured, tell us what we missed.

Methodology & provenance

Spec counts: spck.dev's public register (coverage.json), pinned to release-tag commits (2026-04-08a2d8bf0…); every requirement links to its spec line; method at spck.dev/docs. Live-endpoint data: population frame from the CC-BY-4.0 UCPChecker/ucp-merchants dataset (attribution: UCPChecker on Hugging Face); measurements are our own read-only /.well-known/ucp probe of 2026-07-17; aggregates at scan-summary.json and adoption-facts.json. Ecosystem signals: GitHub, npm, PyPI, crates.io and ucpregistry.com public APIs plus the primary vendor announcements linked inline, captured 2026-07-17. Where a claim is announced but not verifiably live, it is labeled as such. No individual merchant is named or graded; aggregates only. Each edition is point-in-time and reproducible against the same public sources; we plan to refresh it on a monthly cadence and note what changed. Corrections and additions are genuinely welcome — open an issue on GitHub.