OACP explained: one trust layer under UCP, ACP and AP2

Many agent protocols, one shop

Buyers are starting to shop through AI agents. Those agents do not all speak the same language.

UCP (Universal Commerce Protocol) lets an agent discover what a shop sells and run checkout. ACP (Agentic Commerce Protocol) defines a product feed and checkout sessions for agent platforms. AP2 (Agent Payments Protocol) describes mandates: signed proof of what a buyer allowed.

Visa TAP (Trusted Agent Protocol) and Mastercard Agent Pay help a merchant recognise a trusted agent. MCP and A2A connect agents to tools and to each other.

Each protocol is useful. Each one covers one slice of the job, and each tends to arrive with its own kind of agent platform.

What goes wrong when you wire each one yourself

Picture a shop that integrates each protocol separately. It works at first. Then four problems show up.

Several sources of truth. Your price lives in a UCP catalog, an ACP feed and an MCP tool. Change it in one place and the others drift.

Several trust models. Each integration checks keys and identities its own way. A gap in one is a gap in your shop.

Several audit trails. When a buyer disputes an order, the evidence is spread across logs in different formats.

No common off switch. End an offer or block an agent and you must find every place that still uses it. Miss one, and an agent acts on a stale or revoked fact.

OACP in one sentence

OACP, the Open Agentic Commerce Protocol, is one set of signed, revocable commerce facts, one rule-based decision before any money moves, and one tamper-evident record, rendered into every agent protocol.

Think of a building. UCP, ACP and AP2 are rooms. OACP is the foundation and the wiring underneath. It does not replace the rooms. It makes sure every room gets the same facts and follows the same rules.

How it works, step by step

1. You state your facts once. Catalog, prices, stock, policies and payment limits come from the merchant's own systems, such as Shopify.

2. Grantex signs them. Each fact becomes a signed OACP artifact with an expiry time and a slot on a public revocation list.

3. AgenticOrg checks them. It verifies every signature against Grantex's published keys before caching anything. Unsigned, changed, expired or revoked facts are refused.

4. The arbiter decides. Before a purchase, a fixed set of rules says allow or refuse. Nothing waits for a person at the merchant.

5. The ledger records it. Every decision and commerce event joins one hash-chained record that a script can check offline.

6. Adapters speak each protocol. The same facts and decisions become a UCP profile, ACP sessions and feed, AP2-style mandates and MCP checkout tools.

7. Buyer agents see one story. Whichever protocol an agent uses, it gets the same price, the same rules and the same refusals.

Side by side

Here is the same shop, wired two ways. Read across each row.

A purchase, start to finish

Mandates are signed permissions. Grantex issues three of them, in order. Each one points to the one before it.

Intent mandate. What the buyer allowed. For example: up to ₹2,000 at one shop for the next ten minutes.

Cart mandate. The exact cart, fixed by a hash. If the buyer is present, a passkey signs that hash, so the cart cannot change afterwards.

Payment mandate. The amount, the rail (such as Plural, UPI AutoPay or a card network token) and a reference to the payment token. Never the card number.

A cart that goes over its intent, or a payment that does not match its cart, is refused.

In India, RBI rules can require an additional factor of authentication (AFA). Examples are setting up a UPI AutoPay mandate, or a debit above a set limit. OACP adds that step to checkout and the buyer completes it with their bank. When AFA applies, the purchase cannot finish until the bank's confirmation arrives.

Then the arbiter runs eight rules: a valid mandate, active consent, the amount within the buyer's cap, verified buyer authority, facts still valid, merchant limits, stricter limits when the buyer is not present, and AFA evidence when required. If a rule fails, the first failing rule is recorded as the reason.

Only an allow decision lets the payment run, and only once. Grantex countersigns each allow. The payment order carries the decision and the three mandate hashes.

Nobody at the merchant approves anything by hand. The only people involved are buyers confirming their own purchases.

When something is revoked

Say a product is recalled, or an offer ends early. The merchant or an operator revokes the fact once.

Grantex marks it invalid on its public status list and signs a revocation record. Verifiers check that list before they trust a fact. A cached copy of the list lasts 30 seconds by default.

From the next check on, AgenticOrg refuses the fact, the UCP profile stops offering what depended on it, and the arbiter refuses new purchases. Revoking a mandate also revokes the mandates built on it.

If the list cannot be reached, verifiers refuse rather than guess.

Seven reasons to put OACP underneath

Write once, publish everywhere. One set of facts feeds UCP, ACP, AP2-style mandates and MCP. You maintain one source, not one per protocol.

Consistency across agents. Every agent gets the same price, stock and policy, with the same freshness label.

Revocation everywhere at once. One switch withdraws a fact from every protocol.

One audit trail. Decisions, mandates and payments land in one hash-chained ledger. A script verifies an export with no database access, and Grantex can witness the latest chain head.

Protocol changes stay small. UCP's 2026-04-08 release lists a merchant's signing keys in a field called signing_keys. The 2026-08-25 release calls it keys and adds policies and store locations. In OACP that difference lives in one renderer per release. Your facts and rules do not change.

Safety rails every time. No allow decision, no payment. Amount caps, consent, freshness and AFA are checked by the same rules on every protocol.

India rails included. UPI AutoPay mandates, RBI AFA thresholds and the Plural payment rail are part of the design, not an add-on.

Who does what

Grantex is the trust authority. It signs facts, publishes keys and revocation lists, issues mandates, countersigns allow decisions and witnesses ledger heads.

AgenticOrg is the merchant runtime. It connects the shop, verifies and caches facts, runs the arbiter, keeps the ledger and serves each protocol.

The payment provider moves the money. Plural runs payments and the buyer's bank handles AFA. OACP decides whether a payment may start. It never holds funds.

What is switched on today

Status on 20 October 2026.

In Grantex production: every artifact is signed with ES256 under Grantex's first OACP issuer key, the key is published, and the public revocation list is served.

Merged in AgenticOrg's main branch: signature checks before caching (strict in production), the arbiter and the ledger for every commerce handoff and checkout completion, the UCP profile, catalog and checkout, the ACP feed and checkout sessions, MCP checkout tools, Intent, Cart and Payment mandates from Grantex, the Plural payment executor with UPI AutoPay and AFA, and agent request signatures, which are checked and logged by default, with refusing unsigned requests as a separate switch. A handoff without an allow decision is refused. Everything that touches checkout, payment, mandates or public discovery ships behind switches that default to off, so with the defaults no checkout completes and no money moves.

Not yet in AgenticOrg production: the AgenticOrg release described here. Its production deployment is the next step, after which each switch is turned on separately.

That is deliberate. Operators turn each switch on separately, for one merchant at a time, with a recorded way to turn it off again.

What OACP is not

OACP is not a certification, and the groups behind UCP, ACP, AP2 and TAP have not endorsed it. It renders into their published formats and follows their specifications as written.

Two choices are worth knowing. Mandates are signed JWTs mapped to AP2 field names, not AP2's own SD-JWT format. Passkey signing of the cart is a Grantex extension, not part of AP2.

OACP does not establish regulatory compliance on its own. It gives you consistent facts, rules and records to build on.

Is it right for you?

If you sell through more than one kind of agent, take payments through agents, or need one record of who allowed what, a layer underneath saves you from building the same trust plumbing again for each protocol.

If you only answer product questions on one platform and never take payment there, a direct integration may be enough. You can add OACP later without changing your facts.

Earlier posts go deeper on the artifacts themselves and on Grantex's role. The references below link to them and to each protocol's specification.