LCP Explained: The Legal Context Protocol
Depth · Advanced
The Legal Context Protocol (LCP) is an open standard for publishing the legal terms behind an agent transaction in a place an agent can find, in a form it can verify. A business puts one JSON file at a fixed address on its domain, /.well-known/legal-context.json, and that file points to the terms governing any deal done there. The point is to answer three questions the rest of the agentic commerce stack leaves open: what was agreed, under whose law, and what happens if it goes wrong.
Editor’s note. This page describes a protocol that launched in June 2026 and whose specification is published as a draft for community review. It is included because the institutional backing is unusual and the gap it addresses is real, not because it is established. Adoption is unproven. Verify against the primary sources below before making any decision on it.
The gap it is trying to fill
Every protocol the Atlas covers handles a mechanical part of a transaction. MCP handles discovery. ACP and UCP handle the shopping journey and checkout. AP2 handles proof that the user authorized the purchase. x402 and MPP move the money. A2A lets agents coordinate.
None of them says what the parties agreed to, which jurisdiction governs it, or how a dispute gets resolved. On the consumer web this rarely bites, because a human clicked through terms on a page and card-network chargeback rules sit underneath. In agent-mediated commerce both of those assumptions weaken: no human read anything, and a growing share of the value moves over rails that have no chargeback mechanism at all. The Atlas has flagged this before, in risks and readiness: AP2 states plainly that dispute resolution is out of its scope, and its own documentation lists accountability among the open questions.
LCP is one attempt at the missing piece. Whether it is the attempt that wins is a separate question.
How it works
The mechanism is deliberately unremarkable, which is the strongest thing about it. A business serves a JSON file over HTTPS at /.well-known/legal-context.json. It has one required field: the URL of a standalone, downloadable terms document. The comparison LCP draws for itself is robots.txt for crawling rules and /.well-known/openid-configuration for identity discovery. Any agent, on any framework, can make one HTTP request and find out where it stands.
Two optional fields do the heavier lifting. An atrHash is a SHA-256 hash of the terms document, so a party can prove exactly what the terms said at the moment of the transaction rather than arguing about it later. An acceptanceRequired flag, when true, means the counterparty must digitally sign the terms before transacting, producing cryptographic evidence of explicit consent.
The specification recommends machine-readable formats for the terms document itself, Markdown, JSON, or plain text, and notes that PDF and Word are poorly suited to automated parsing. That is a small detail with a real consequence for merchants: the terms of service you already publish as a web page may not be usable as-is.
The four levels of trust
LCP frames adoption as four levels, described in the specification as advisory guidance rather than a normative requirement. Each is independently useful, and a business can implement one without the others.
| Level | Name | What it adds |
|---|---|---|
| 1 | Informational | The terms are discoverable at a known URL. Proceeding implies consent. No hash, no signature. |
| 2 | Provable | An atrHash proves the terms have not changed since the transaction. |
| 3 | Signed | A digital signature binds a specific party to a specific document. Proof of explicit intent. |
| 4 | Integrated | Hooks into dispute resolution, escrow, compliance, and other recourse infrastructure. |
Level 3 is bilateral, and this is the part most relevant to anyone actually running agents. The service publishes terms; the buyer’s principal publishes a policy stating what it will accept: a minimum trust level, acceptable jurisdictions, acceptable dispute methods, a cap on the commitment size, and a signing threshold above which the agent’s signing key is gated behind human review. That is a concrete answer to a question buyers keep asking, which is how you stop an agent from agreeing to something you would never have agreed to.
Who is behind it
LCP launched on 24 June 2026. It is co-stewarded by two Founding Maintainers: Integra Ledger, the protocol’s creator and technology steward, and the American Arbitration Association-International Centre for Dispute Resolution (AAA-ICDR), which describes itself as the world’s largest private provider of alternative dispute resolution and marks its centennial in 2026.
That pairing is the genuinely interesting part. Most new standards in this space are backed by technology companies, and their credibility rests on distribution. LCP’s second steward is an adjudication institution, and it is the only entity in agentic commerce standards-setting that actually resolves disputes for a living.
Founding contributors named in the launch announcement include Google, IBM, Circle, Wayfair, Stellar Development Foundation, Ava Labs, UiPath, Cardano, Hedera, Crossmint, Pinata, Aptos Foundation, Baselayer, Trinsic, First Person Cooperative, Sei Labs, and Mysten Labs. Two of those, Google and Wayfair, are already central to UCP, and Circle is in the x402 ecosystem, so this is not a set of names disconnected from the rest of the map. It is also, notably, heavy on blockchain foundations and light on merchants, payment networks, and the AI platforms that operate the agents.
The protocol is Apache 2.0 licensed with no fees at any level. Governance runs through a contribution-based technical steering committee of up to seven seats, with changes made via public enhancement proposals and a contributor licence agreement required. The launch announcement states that governance is designed to transition to a neutral foundation, which has not yet happened.
How mature is it, really
This is where a neutral reference has to be blunt, because the framing around LCP runs ahead of its state.
The specification is versioned v1.0 but labelled on LCP’s own site as a draft released for community review. The public repository is small: a handful of commits, no tagged releases, and a star count in the teens as of early August 2026. Those are early-project numbers, not adoption numbers.
More importantly, none of the protocols LCP proposes to attach to has adopted it. LCP’s documentation is unusually honest about this, splitting integrations into two tiers: Tier A mechanisms that work today against stock, unmodified protocols by borrowing an existing extension surface, and Tier B mechanisms that would need a change to the other protocol’s specification. Every Tier A route is a workaround. For ACP it means putting a legalContext value in checkout-session metadata, because the relevant enum is closed. For Visa’s Trusted Agent Protocol it means a custom HTTP header sitting outside the signature chain, which LCP itself labels advisory. The first-class integrations, a legalContext field in the MPP payment challenge, a registered x402 extension identifier, a field inside an AP2 signed mandate, are all Tier B, all proposed, and all dependent on stewards LCP describes itself as inviting.
So the accurate summary is: a well-designed proposal with a serious institutional sponsor, published openly, addressing a real and undersupplied gap, and not yet adopted by anyone whose adoption would matter.
What it means for you
If you are a merchant or operator, the useful action is not to implement LCP. It is to check whether you could. Ask whether your terms of service exist as a standalone, hashable, machine-readable document rather than only as a web page, and whether you know which jurisdiction and dispute process govern a sale an agent completes on your site. Those questions are worth answering regardless of which standard eventually wins, and most organizations cannot currently answer them.
If you are a builder, the buyer-policy model is worth reading even if you never adopt the protocol. Encoding acceptable jurisdictions, dispute methods, commitment caps, and a human-review threshold as machine-checkable policy is a pattern that will show up in agent governance whatever the wire format ends up being.
If you are watching the landscape, treat LCP as the leading candidate in an emerging category rather than as part of the stack. The signals to watch are whether any of ACP, UCP, AP2, x402, or MPP accepts one of the Tier B proposals, whether the promised transition to a neutral foundation happens, and whether a merchant or payment network joins the contributor list. Until at least one of those occurs, this is a proposal with a good pedigree.
FAQ
What is the Legal Context Protocol? An open standard for publishing the legal terms behind an agent transaction at /.well-known/legal-context.json, with optional hash-proof of the terms and optional signed acceptance. It covers what was agreed, under which law, and with what recourse.
Who is behind it? Integra Ledger and the American Arbitration Association-International Centre for Dispute Resolution, as Founding Maintainers, with founding contributors including Google, IBM, Circle, Wayfair, and Mysten Labs. Launched 24 June 2026 under Apache 2.0.
Does it compete with ACP, UCP, AP2, x402, or MPP? No. It is designed to attach to them and addresses the recourse layer that all of them leave out of scope.
Is it being used yet? Not meaningfully. The v1.0 specification is a draft for community review, the repository is early, and none of the protocols it proposes to bind to has adopted it.