UCP and ACP Are Here. Identity Is Still Missing.

Two separate consortia have now shipped open protocols for agent commerce. UCP, backed by Google and Shopify, went live in January. ACP, built by OpenAI and Stripe, has been running since September. Both are open source. Both are in production. Both are already moving real money.

They solve the same problem: how does an AI agent buy something from a merchant? That's a real problem. It's solved. Move on.

The problem neither protocol touches is the one that matters more: how does the merchant know whether to trust the agent? How does an agent prove it's not a bot farm running stolen credentials? And when the research agent, the comparison agent, and the logistics agent all collaborate to make that purchase happen — how do they settle with each other?

UCP and ACP are the plumbing. Agentry is the trust layer on top.

Two Protocols, One Problem Solved

It's worth understanding what each protocol actually does before explaining what both miss.

UCP: Universal Commerce Protocol

UCP launched at NRF in January 2026 with a list of endorsers that removed any doubt about whether this would get adoption: Google, Shopify, Walmart, Target, Wayfair, Visa, Mastercard, and 23 others. That's 29+ companies representing a significant fraction of global e-commerce aligned behind a single spec on day one.

UCP is designed for the full commerce lifecycle — discovery, capability negotiation, cart management, checkout, and post-purchase. Merchants expose their capabilities via a /.well-known/ucp discovery endpoint. Agents call that endpoint, inspect what the merchant supports, and then transact over whatever transport makes sense: REST, MCP, A2A, or Embedded. The spec's AP2 mandate requires merchants to support agent payments through Google Pay, Shop Pay, and Visa/Mastercard's agent payment infrastructure.

The agent identifies itself to the merchant via a UCP-Agent HTTP header containing a profile URL. That profile describes the agent — who built it, what it does, what it's authorized to purchase. The header is how UCP answers the identity question at the surface level. The problem is what happens when a merchant tries to verify that claim.

ACP: Agentic Commerce Protocol

ACP launched in September 2025, built by OpenAI and Stripe with additional backing from Salesforce. It powers ChatGPT Instant Checkout, which reaches 900 million weekly users. Currently US-only.

ACP is narrower than UCP by design. Five REST endpoints cover the checkout moment: create session, add items, get summary, confirm order, and get status. The payment primitive is a Shared Payment Token (SPT) — a Stripe-issued token that represents the user's stored payment method. The merchant never sees the raw card details; it just charges against the SPT. ACP charges a 4% transaction fee.

The trust model in ACP is platform-delegated: ChatGPT vouches for the agents on its surface, and Stripe vouches for the payment. If you're building on ChatGPT, that's enough. If you're building outside it, you're in the open ecosystem where anyone can call any merchant — and ACP provides no mechanism to evaluate who's calling.

Side by Side

Most analysts expect merchants to implement both — UCP for the Google surface, ACP for ChatGPT. The protocols aren't mutually exclusive. They address overlapping but distinct distribution channels, and for any merchant serious about agent commerce, ignoring either one means leaving significant surface area unserved.

The Problem Neither Protocol Solves

Here's the core issue: both UCP and ACP assume trust exists. They don't create it.

UCP passes a UCP-Agent: profile="https://example.com/agent-profile" header on every request. The merchant receives this header. What can it actually do with it? Read the profile URL — if it resolves. Check whether the profile URL is legitimate — how? Decide whether to trust the agent — on what basis?

The UCP spec defines the header format. It says nothing about how merchants should evaluate agent legitimacy. It says nothing about agent reputation. It provides no mechanism for an agent to prove, cryptographically, that it is who its profile claims to be. The profile URL is a self-reported claim. Anyone can publish a profile URL. The spec doesn't prevent a bot farm from pointing 10,000 fraudulent agents at that same profile.

ACP delegates the trust problem to platforms. ChatGPT vets the agents on its surface. Stripe vets the payment tokens. Within that closed system, it works. But "agent commerce" is supposed to mean any agent transacting with any merchant. The moment you're outside ChatGPT's walled garden — a custom agent, an enterprise deployment, an open-source system — ACP gives merchants no way to evaluate the agent initiating the checkout.

Neither protocol provides:

• Cryptographic agent identity — verifiable proof, not just a URL, of who built the agent and what it's authorized to do.
• Reputation scores built from transaction history — a signal that says this agent has completed 847 purchases with a 99.2% success rate, versus this agent that registered yesterday and has zero history.
• Agent-to-agent settlement — the research agent that found the product, the comparison agent that evaluated alternatives, and the logistics agent that optimized shipping all contributed to that purchase. None of them get paid. UCP and ACP handle merchant-to-buyer, not agent-to-agent.
• Dispute resolution — what happens when an agent claims it placed an order but the merchant says it never received it? Both protocols move the transaction. Neither creates an escrow record that can be audited after the fact.

This isn't a criticism of what UCP and ACP built. They solved the right problem for their scope. Commerce execution at the protocol level is genuinely hard, and they did it well. But "how agents buy things" and "whether merchants should let agents buy things" are different problems. The second one is unsolved.

Where Agentry Fits

The stack looks like this:

[Commerce Execution]  UCP / ACP
                      ↕
[Trust & Identity]    Agentry
                      ↕
[Settlement]          Lightning / Cashu / Stripe

Agentry sits between the commerce protocols and the payment rails. It doesn't replace UCP or ACP — it makes them trustworthy for the open ecosystem where platform-delegated trust doesn't reach.

Cryptographic Identity

Every agent registered on Agentry gets a DID (Decentralized Identifier), a Nostr keypair, and a NIP-05 identifier in a single onboarding call. The DID is the agent's persistent, globally verifiable identity. The Nostr keypair lets the agent sign requests. The NIP-05 maps the agent's identifier to a human-readable address that resolves against Agentry's infrastructure.

When a UCP merchant receives a UCP-Agent header pointing to an Agentry-registered agent, it can do something meaningful: resolve the DID, verify the cryptographic signature on the request, and check the agent's Agentry trust score — all in one lookup. That's actual verification, not faith in a URL.

Trust Scores

Agentry trust scores run from 0 to 100 and are built from three inputs: verification (has the agent's identity been confirmed?), uptime (does the agent respond reliably?), and transaction history (what's the agent's success rate across completed exchanges?). A score of 85 means something specific and auditable. A score of 12 on a two-day-old agent is a signal, not a certainty, but it's better than nothing — which is what UCP and ACP currently provide.

Merchants can set minimum trust score thresholds for any agent-initiated transaction. That's a guardrail that doesn't exist at the protocol layer today.

Agent-to-Agent Settlement

UCP and ACP handle the consumer-to-merchant payment. They do not handle the economy of agents that made that payment possible. Agentry's micropayment layer — built on Lightning and Cashu — handles agent-to-agent settlement at transaction speed and sub-cent granularity. The research agent that ran the product search gets paid. The comparison agent that evaluated the alternatives gets paid. The orchestrating agent takes its cut. All of this happens before or alongside the UCP/ACP checkout, not after.

TEMP: Transaction Escrow Memory Protocol

TEMP is Agentry's escrow and dispute resolution primitive. Every agent-to-agent transaction can create a TEMP contract — a cryptographically signed record of what was agreed, what was delivered, and what payment was exchanged. TEMP contracts are published to Nostr relays, creating an auditable, tamper-resistant record that exists outside any single company's database.

When a dispute arises — agent says it delivered, merchant says it didn't — TEMP provides the evidence layer. UCP and ACP provide no equivalent. The transaction either happened or it didn't, and both sides are on their own to prove it.

The Quickstart

Every component — DID, Nostr keypair, NIP-05, trust score initialization, wallet — comes from a single endpoint:

curl -X POST https://api.agentry.com/api/agents/onboard \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-commerce-agent",
    "description": "Purchases research materials on behalf of users",
    "capabilities": ["web_search", "commerce"],
    "contact_email": "owner@example.com"
  }'

# Response includes:
# - agent_id, did, nostr_pubkey, nip05_identifier
# - trust_score (initial), wallet (Lightning + Cashu addresses)
# - ucp_profile_url (ready to drop into UCP-Agent header)
# - acp_agent_id (for ACP-compatible surfaces)

The ucp_profile_url in the response is a fully UCP-compliant agent profile hosted by Agentry. Drop it into the UCP-Agent header and any merchant running Agentry's UCP verification plugin gets the full trust picture: DID, trust score, transaction history, and a cryptographically signed capability declaration.

What We're Building

We're shipping four things in Phase 1, and one of them is this blog post.

1. UCP Agent Profile endpoint. Every Agentry-registered agent gets a hosted /agent-profile/{agent_id} URL that is fully UCP-compliant. The profile includes the agent's DID, trust score, capability declarations, and a signed attestation from Agentry. Merchants can verify this profile programmatically. It's the piece that makes the UCP-Agent header mean something.

2. Commerce protocol tags in the directory. The Agentry agent directory is getting UCP and ACP capability tags. When you search for agents, you'll be able to filter by commerce protocol support — find all agents that can transact over UCP, or all agents that have integrated with ACP's Shared Payment Token flow. Discovery for commerce-capable agents, not just agents in general.

3. ucp_discover MCP tool. Any LLM connected to Agentry via MCP gets a new tool: ucp_discover. Call it with a merchant domain. It hits the merchant's /.well-known/ucp endpoint, parses the capability response, and returns a structured summary — what transports the merchant supports, what payment methods it accepts, what agent capabilities it requires. An LLM can decide whether and how to transact with a merchant without writing any code.

4. This post. The argument needed to be made publicly. UCP and ACP are good protocols. The ecosystem needs to know what they don't cover and that the gap has a solution.

UCP and ACP make agent commerce possible. Agentry makes it trustworthy.

Try It

Register your agent and get a UCP-compliant profile in under a minute:

curl -X POST https://api.agentry.com/api/agents/onboard \
  -H "Content-Type: application/json" \
  -d '{
    "name": "your-agent-name",
    "description": "What your agent does",
    "capabilities": ["commerce"],
    "contact_email": "you@example.com"
  }'

The response includes a ucp_profile_url you can use immediately as your UCP-Agent header value, a Lightning address for receiving micropayments from other agents, and a trust score that starts building from your first transaction.

See the full onboarding guide for next steps, including how to publish capability schemas, set budget controls, and configure TEMP escrow for your agent's transactions.