Legal Context ProtocolProtocol Integration
How legal context references embed in existing agentic commerce protocols via extension mechanisms and spec contributions.
This section is advisory.
This section defines the abstract integration interface for embedding LCP references inside the carriers exposed by other protocols. Two supporting pages do the work:
- Naming Conventions — how LCP references are encoded in string fields, structured JSON, and raw-byte carriers.
- On-Chain Binding Patterns — the abstract pattern vocabulary (Native Field, Overlay Contract, Sidecar Attestation, Opaque Challenge, Id-Reuse, Protocol Extension) with two evaluation axes (wire compatibility, adoption cost) and three recovery properties (on-chain, zero-party recoverable, forward-indexable).
The integration interface is protocol-agnostic and chain-agnostic. The standard does not endorse or canonize any particular per-protocol integration profile or per-chain binding profile — protocol stewards and chain operators are invited to publish authoritative profiles in their own documentation.
The LCP verification gate itself — fetch terms, recompute hash, evaluate buyer policy — runs client-side, around any payment or authorization protocol. This is what makes integration additive rather than invasive: LCP fields ride inside existing carriers without modifying carrier semantics.
Per-Protocol Illustrations
The per-protocol pages below describe current integration possibilities for each protocol — what extension points the protocol exposes today, what each path would look like, and what would require upstream coordination. The illustrations are non-prescriptive; protocol stewards are invited to publish authoritative LCP integration guidance for their protocols.
| Protocol | Tier A available today | Page |
|---|---|---|
| MPP | LCP fields inside HMAC-covered request.methodDetails | MPP |
| ACP | Freeform session metadata / links array | ACP |
| x402 | accepts[].extra and top-level extensions (v2) | x402 |
| UCP | Existing links array (Level 1 only) | UCP |
| AP2 | Alongside mandates in transport metadata | AP2 |
| Visa TAP | Custom HTTP header in signed components | Visa TAP |
| Mastercard Verifiable Intent | Custom Layer 2 constraint (URN / reverse-domain namespaced) | Mastercard |
| A2A | Task metadata and Agent Card extensions | A2A |
| MCP | Tool annotations and description field | MCP |
Design Principle
LCP is complementary to every protocol above. It provides the legal layer that each defers. The protocols handle payments, checkout, fulfillment, and authorization. LCP handles terms, verification, signed acceptance, and recourse. The patterns and integration illustrations show where these layers connect — without prescribing how any specific protocol must implement the connection.