Standards landscape
Where VCP sits among the agentic-commerce protocols, and how it references — rather than vendors — each of them.
VCP is the bilateral agent transaction layer for vibe commerce. It owns negotiation, offer commitment, platform match certificates, private-utility boundaries, governance, and replayable state-diff evidence. It does not duplicate commodity commerce plumbing. Where an industry protocol already has the right shape, VCP borrows its conventions at the schema layer and projects onto it through an adapter — using it below or beside VCP, not instead of VCP. The sections below place each protocol on that map; every claim here is grounded in the protocol-landscape decision doc.
The protocols
MCP — Model Context Protocol
MCP standardizes how a model invokes tools. In VCP, an MCP-style Tool Router rides underthe protocol for non-critical tool execution without overriding VCP semantics — the transaction record, permissions, and evidence chain remain VCP's. MCP is a tool-call layer, not a commerce or settlement layer, so VCP references it as the substrate for tool calls rather than as a transaction protocol.
A2A — Agent-to-Agent messaging
A2A provides an agent messaging envelope (its Message / Task shapes) and is the transport that overlays such as AP2 and x402 ride on. VCP keeps its own universal envelope and in-process evidence bus by default rather than committing to A2A as the internal bus; production adapters can speak A2A-based protocols externally while VCP preserves its transaction record internally.
AP2 — Agent Payments Protocol
AP2 (Google) supplies the authorization vocabulary through its Intent / Cart / Payment mandate triad, including the open-versus-closed mandate distinction. AP2 is an overlay, not a commerce or negotiation protocol. VCP borrows the triad wholesale as the payload schema for delegate.create_purchase_mandate, commerce.create_cart, and platform.authorize_payment, and wraps it inside richer buyer and seller mandate objects that add the authorityblock. VCP enforces the do-not-share fields through its role-partition router rather than AP2's SD-JWT selective disclosure by default.
ACP — Agentic Commerce Protocol
ACP (OpenAI + Stripe) is a strong checkout and delegated-payment target: it gives useful field names, idempotency conventions, and a concrete REST path. But it assumes an authoritative merchant cart and deliberately excludes seller-side negotiation, platform match attestation, and private-utility boundaries. VCP projects onto ACP at the checkout adapter — VCP's session_id maps to ACP's checkout_session_id, the mandatory Idempotency-Key contract is adopted verbatim, and money is carried in integer minor units throughout.
UCP — Universal Commerce Protocol
UCP (Google) is the natural production substrate for commerce interoperability: capability discovery, product / cart / checkout / post-purchase surfaces, and merchant ecosystem integration. VCP projects to UCP at the adapter boundary rather than forcing merchants to speak a research-native bus. UCP is the preferred production commerce substrate, but it does not replace VCP's bilateral transaction record — negotiation commitments, match certificates, private-utility enforcement, and replayable state-diffs.
x402 — settlement rail (a2a-x402)
x402, via a2a-x402, is a settlement-rail candidate built on A2A messages, with a six-state payment lifecycle and a defined error-code taxonomy. VCP treats it as an optional settlement-rail variant, useful when the question is paid access or rail-specific adversarial behavior rather than whether two agents truthfully reached a verifiable commerce commitment. Because the envelope is VCP's own, elevating x402 from optional variant to first-class rail is a payload-schema change, not a protocol change.
Projection cross-walk
VCP references prior art at the schema layer rather than adopting any one protocol whole. The key projections — session identity, idempotency, the mandate triad, and money units:
# session / id cross-walk (projection, not a 1:1 rename)
VCP session_id -> ACP checkout_session_id # at the checkout adapter
VCP idempotency_key -> ACP Idempotency-Key # adopted verbatim (>=24h retention)
VCP delegate.create_purchase_mandate -> AP2 Intent Mandate
VCP commerce.create_cart -> AP2 Cart Mandate
VCP platform.authorize_payment -> AP2 Payment Mandate
money: integer minor units everywhere (borrowed from ACP)Layer and role summary
| MCP | A2A | AP2 | ACP | UCP | VCP | |
|---|---|---|---|---|---|---|
| Layer | Tool calls | Transport / messaging | Authorization overlay | Checkout + settlement | Commerce interop | Bilateral transaction record |
| Role for VCP | Tool router underneath | External transport | Mandate vocabulary | Checkout adapter | Production substrate | Owns the record |
| Relation | Rides under | Projects onto | Borrows wholesale | Projects onto | Projects onto | — |
- Layer
- Tool calls
- Role for VCP
- Tool router underneath
- Relation
- Rides under
- Layer
- Transport / messaging
- Role for VCP
- External transport
- Relation
- Projects onto
- Layer
- Authorization overlay
- Role for VCP
- Mandate vocabulary
- Relation
- Borrows wholesale
- Layer
- Checkout + settlement
- Role for VCP
- Checkout adapter
- Relation
- Projects onto
- Layer
- Commerce interop
- Role for VCP
- Production substrate
- Relation
- Projects onto
- Layer
- Bilateral transaction record
- Role for VCP
- Owns the record
- Relation
- —
The layers are not competitors stacked against VCP; they are the places VCP plugs in. VCP owns transport and envelope (its own bus), the bilateral parts of the action vocabulary, and its verification objects; ACP, AP2, UCP, and x402 remain adapter targets and payload sources where they already solve the problem.
- Borrow at the schema layer: ACP idempotency and minor-unit money, AP2 mandate names.
- Project at the adapter boundary: UCP for interop, ACP for checkout, x402 as an optional rail.
- Own outright: the universal envelope, bilateral negotiation verbs, match certificates, private-utility enforcement, and replayable state-diff evidence.