Developers/Standards landscape
REFERENCE

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:

cross-walk.txt
# 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
Layer
Tool calls
Role for VCP
Tool router underneath
Relation
Rides under
A2A
Layer
Transport / messaging
Role for VCP
External transport
Relation
Projects onto
AP2
Layer
Authorization overlay
Role for VCP
Mandate vocabulary
Relation
Borrows wholesale
ACP
Layer
Checkout + settlement
Role for VCP
Checkout adapter
Relation
Projects onto
UCP
Layer
Commerce interop
Role for VCP
Production substrate
Relation
Projects onto
VCP
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.
Go deeper
For the positive scope of VCP and a side-by-side comparison of what each protocol standardizes, see /developers/concepts — Core concepts.