Protocol Integration

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.
• Settlement 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.

The host protocol governs. Where anything on these pages conflicts with what a host protocol's own specification permits, the host protocol is correct and this page is wrong. These are observations about other people's standards, made from outside them. No field spelling here should be treated as a target: the correct placement is whatever the host's live specification permits on the day of implementation. Examples are abbreviated — they show where an LCP reference sits, not a complete host document. Build from the host schema, never from an example here.

These illustrations age. The protocols described are young and revise quickly, and rendered documentation drifts from primary artifacts. Every illustration was re-verified against the host protocol's own primary artifact — the JSON Schema, the .proto, the Internet-Draft source, the reference implementation — read directly on 2026-09-07. Re-verify against the host's live specification before building.

----------|-----------------------|------| | MPP | LCP fields inside HMAC-covered request.methodDetails | MPP | | ACP | legalContext in checkout-session metadata (the links type enum is closed) | 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 | None — verifiers reject unknown constraint types; registration is the path | 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.