Seven months in, UCP shipped its most consequential release yet — onto a fleet finally large enough to carry it.

On August 25th the protocol shipped v2026-08-25, the release that stopped UCP being shopping-shaped: payment lifted out of shopping into common, location became a first-class capability, quantities learned fractions, and 3D Secure arrived without a vendor attached. Underneath it, the census now covers 15,735 verified stores — and the score board, not the headcount, is the number that describes them: a modal score of 96, 93% of the fleet in the A band, and 99.8% on a single spec version.

Those two facts together are the report. The protocol now has the vocabulary for a complete purchase, and an installed base big enough that switching one thing on moves tens of thousands of storefronts at once. What August shows is where that handoff stands, and — more useful than any single number — how a fleet shaped like this one actually takes up a release.

#The numbers

15,735 verified stores of 19,336 domains monitored (July's report covers the previous census). What the score board says about that fleet:

• Modal score 96 — six integer values hold 84% of all verified stores
• 14,709 A · 1,025 B · 1 C — 93% of the fleet in one grade band
• 99.82% declaring a single spec version, one day after the August release
• 0.11% declared-versus-actual gap on catalog (15,680 declared, 15,662 resolving)
• 27 stores declaring identity linking, 18 of them unconfigured · 4 declaring a payment token, none a production storefront

Figures are a point-in-time census as of August 26, 2026.

#What the score says

The UCP Score is the summary metric for everything else in this report: a 0–100 grade across Discovery, Conformance and Capability, computed identically for every store, with the weighting published. From this month the model is versioned — v1.0.0, fixed on August 25 — so a score in September means the same thing as a score in August, and where the model changes we say so rather than quietly rescoring history.

Read the distribution first, because it is not the shape a distribution normally has.

It is not a curve — it is a set of towers. 6,130 stores share the exact score 96; another 2,133 share 95; 1,912 share 89. Six values account for 84% of the fleet. What looks like a distribution of fifteen thousand merchants is a handful of templates, repeated — and that is the single most useful thing the score tells you about this ecosystem right now.

The grade bands compress the same fact into three rows: 14,709 A, 1,025 B, a single C. That A share — 93% — is essentially where it stood in June (~94%), across a fleet that has changed shape considerably since. The score has not moved because the templates have not moved. When 93% of a fleet lands in one band, the band has stopped describing merchants and started describing the handful of templates they were built from.

Which raises the question the rest of this report answers: why 96 and not 100? The towers sit where they do because of what the templates declare — and, further down, because of what they leave out. Decompose the score by capability and the shape appears immediately:

The shape is familiar from June and July, but the two-thirds line in the middle is not what it appears to be. It looks like a step — as though a third of merchants had chosen not to implement cart and order. Split the same rows by platform and the step disappears: Shopify publishes all four at 100%, Wix publishes catalog and checkout at 100% and cart and order at 0%, and not one store in either fleet deviates. The 66.6% is not a choice made by merchants. It is the boundary between two templates, and we return to it below.

#The payment line, answered

Last month we said the single most important number on the board was whether payment moved off zero, and that we'd watch it daily. Here is the honest answer.

Four verified stores in the census declare a payment token. Not one of them is a production storefront on a commerce platform. The set is a reserved-TLD test fixture and its staging twin, a deployment on a developer hosting platform, and one independent domain. A fifth profile that declared payment is currently unreachable. Worth separating from the rails themselves, which are live and expanding — Mercado Pago brought Pix and instalments to UCP's payment extensions in July.

So the truthful reading is not "payment moved off zero." It is that payment has not started, and the only profiles declaring it are the ones you would expect to find in a conformance lab: fixtures, demos, and development deployments. We could have reported a number that went from 0 to 4 and called it a trend. It isn't one, and the distinction between a fixture and a merchant is exactly the kind of thing a census is for.

The same discipline applies to the line above it. Identity is the layer where KYC, KYB and KYA meet, and twenty-seven stores declare identity linking — but 18 of those 27 declare it without configuring it. Two-thirds of the identity claims in the fleet resolve to nothing. A capability that is declared but unconfigured is worse than absent: an agent reads the manifest, plans a flow around it, and fails at the moment it tries to use it. It is the same failure shape we found running real models through real checkouts.

That gap is the reason we measure both what a store says and what its endpoints actually do — protocol design and the validation layer are two halves of the same job. Where the fleet is honest, it is very honest: of 15,680 stores declaring a catalog, 15,662 resolve — a declared-versus-actual gap of 0.11%. The catalog layer works. The identity layer is mostly claim.

#How a fleet this uniform takes up a release

In July we praised the version discipline: 99.7% of the fleet on a single spec revision, remarkable for a protocol six months old. That number is now 99.82% on 2026-04-08, with the August release one day old.

Two stores on day two is exactly what you would expect, and it is worth saying plainly: nobody ships a breaking spec change across a billion-dollar commerce platform overnight. Shopify and Wix carry millions of merchants between them, and a version bump on that scale is a release train — QA, staged rollout, merchant comms, support readiness. Day two was never going to be the number. The month the template moves is.

What makes this fleet unusual is that when it does move, it will move in cohorts rather than a trickle. There is no long tail of independently-maintained integrations to drag along: the version a store declares is the version its platform declares. That is the same property that gave UCP its version discipline in the first place, and it cuts strongly in adoption's favour once a platform commits — one template update carries tens of thousands of storefronts in a single deploy. Very few protocols get to migrate that cleanly.

The August release leans into exactly that. Among its breaking changes is a rule that a profile declaring a version must declare that same version on every dev.ucp.* service, capability and extension entry — and that a platform encountering an entry on a different version must treat it as absent. Partial migration isn't a slow drift; it is a clean per-store cutover. For a platform-led ecosystem that is the right design: the moment a template ships, every store's state is unambiguous.

So September's question is a scheduling one rather than an adoption one. The event to watch for is the first platform template declaring 2026-08-25 — everything else follows it.

Two other breaking changes are worth checking today, and both are silent failures rather than errors. dev.ucp.shopping.ap2_mandate became dev.ucp.common.payment.ap2_mandate, so anything keyed to the old string finds nothing rather than complaining — a reminder that the namespace is the contract. And signing_keys[] was removed outright in favour of keys[] — not deprecated, removed. If you publish keys, it is worth re-reading how every UCP request proves who sent it before you touch that field. We covered the full list, including what does not need migrating, in the release write-up.

#Wix arrives, and the template becomes the unit of adoption

July called Wix flipping payment "the highest-leverage number on the board," on the reasoning that a platform template turns capability on in tens of thousands, not ones.

The first half happened. Wix is now 5,277 domains, 5,198 of them verified — roughly a third of the entire verified fleet, a scale only a platform can produce, as Shopify's UCP CLI showed from the other direction.

The second half did not. Across all 5,198 Wix storefronts: zero payment tokens, zero identity linking.

This is the clearest evidence yet for something the census has been hinting at all year: platform template determines capability, and merchants do not deviate from it. Not "rarely" — the split is total. Across 10,409 verified Shopify storefronts, catalog, checkout, cart and order all sit at exactly 100%. Across 5,198 Wix storefronts, catalog and checkout sit at exactly 100% and cart and order at exactly 0%. There is no middle, no long tail of merchants who went further than their platform or fell short of it.

That is the set of towers we opened with, seen from the inside — the platform split is the score distribution.

That is not a criticism of any platform. It is a structural fact about how this ecosystem will actually turn capabilities on, and it should change where anyone waiting on transactable UCP directs their attention. The unit of adoption is not the merchant. It is the template.

#Transport: MCP is winning

One line that has quietly resolved. Across the verified fleet: MCP 15,855, embedded 10,509, REST 5,424, A2A 3, redirect 1.

MCP is now effectively universal — every verified store exposes it, most alongside an embedded surface. The multi-transport debate that ran through the spring is settling in practice, whatever the spec permits. If you are building an agent, MCP is the surface that reaches the whole fleet — and if you are a merchant, whether your store is WebMCP and UCP ready is now mostly a question about your platform — which is why we put a public MCP server in front of the census.

The single redirect entry remains a non-spec transport pattern rather than a trend.

#What the spec actually did

The release deserves more than a version bump, because it changed what UCP is for.

Moving payment into common and making token binding vertical-agnostic is what lets a hotel or a restaurant express itself without fabricating a shopping cart. Location search and lookup — the where primitive to sit alongside what and how — is what makes click-and-collect, pickup and physical properties expressible at all. We tested what lodging and restaurants would need months before the primitives existed; what shipped is recognisably the missing piece, and it lands with the Lodging Technical Council seated to build on it.

On the payment side, 3DS2 without a vendor, payment terms, split payments and the Actions primitive together close the gap we described in the messy middle: discovery was never the hard part. The step-up challenge, the pay-in-four, the deferred obligation that has to survive to the receipt — that is where checkouts get difficult, and this is the release where the protocol stopped leaving it to the platform.

Which makes the census reading sharper, not softer. Every technical blocker we have cited since February is now resolved in the specification. Payment authorisation, step-up authentication, negotiated terms, identity binding, fulfillment context. The protocol is no longer the thing standing between an agent and a completed purchase at the median store. What stands there now is deployment.

#What to watch in September

• Where the towers move. The score distribution is the tell for everything below: the first template to migrate will move a whole tower at once, and the release's new conformance rules (version-match, keys[]) land in the Conformance leg under the versioned model — so a tower shifting is a template shifting, never a rescoring.
• Whether any platform template declares 2026-08-25. The single number that matters. One template moving takes thousands of stores with it; nothing else in this report moves the fleet.
• The AP2 rename biting. Anything keyed to dev.ucp.shopping.ap2_mandate now silently finds nothing. Expect a quiet wave of integrations that stop working without erroring — the worst failure mode there is.
• signing_keys[] stragglers. Stores declaring the new version while still publishing a removed field. We flag it in monitoring, on every status page, and across the trust layer we review each month.
• Identity linking's configured share. 27 declared, 18 unconfigured. If that ratio improves, identity is becoming real; if the declared number grows while the configured number doesn't, it is becoming decoration.
• The first non-shopping vertical profile in the wild. The primitives now exist. A live lodging or food manifest using common location would be the first evidence the multi-vertical thesis has left the council room. We track each vertical at ucpchecker.com/verticals.
• Whether payment stays a lab phenomenon. The honest test is a payment token on a production storefront belonging to a real merchant on a real platform. Everything before that is conformance testing.

Seven months in, the argument has moved twice. It is no longer whether stores will adopt UCP — 15,735 verified storefronts settled that. It is no longer whether the protocol can express a complete purchase — the August release settled that. What remains is the most tractable problem UCP has faced yet: a template update and a payment method, on platforms that have already shown they can move their whole fleet in a single deploy. The hard architectural questions are behind it. This one is a matter of scheduling.

We'll see you in September.