Code is Not Law: Legal Context Protocol

Key Takeaways

• On June 24, a consortium that includes the American Arbitration Association and Integra Ledger unveiled the Legal Context Protocol. The standard begins from a single concern: as transactions in which agents pay and accept terms on behalf of people grow, the layer that records which terms applied, under which jurisdiction's law a deal took place, and what procedure to follow when something goes wrong has been left empty.
• LCP is not a standard that proposes new technology, but one that standardizes where terms are placed. It asks every service to put a JSON file containing the address of its terms document at a fixed path, then layers hash verification, signed consent, and dispute resolution links on top of that as optional steps in a four-tier structure. LCP does not require blockchain; it works with any web server that supports HTTPS.
• The interesting part is that, instead of settling agent transactions on-chain, LCP routes them back to the existing human legal system. The standard does not require any particular chain, but the upper tiers that build toward verification, signing, and storage rely on methods such as hashing and content addressing, which blockchains can provide in a more trustworthy form. Many of the chains that joined as founding contributors have long aimed at real-world assets and payments, and among them Sui is positioned to connect its own storage and encryption stack directly to those upper tiers.

1. LCP, the Legal Layer of Agentic Commerce

Source: AAA

On June 24, the American Arbitration Association (AAA) and Integra Ledger released an open standard called the Legal Context Protocol (LCP). LCP aims to make legal terms, consent, and dispute resolution procedures discoverable and verifiable when agents transact on behalf of people or organizations. A range of infrastructure and blockchain companies joined as early contributors, including Google, IBM, Circle, Mysten Labs, Sei Labs, Aptos, Ava Labs, and Stellar.

Over the past year, protocols for payments and identity verification have appeared quickly in agentic commerce. From Stripe and Tempo Labs' Machine Payments Protocol (MCP), to x402 led by Coinbase and Cloudflare, to OpenAI and Stripe's Agentic Commerce Protocol (ACP), to the Universal Commerce Protocol (UCP) that Google built with several retailers, to Visa's Trusted Agent Protocol and Mastercard's Verifiable Intent, a good deal of infrastructure for agent payments and identity proof has already emerged.

Yet despite all these protocols, the legal domain has remained empty. Payment protocols handle how much was paid, and identity and authorization protocols handle who approved the transaction, but neither records which terms governed the deal, which country's law applies, or what remedy is available when things go wrong. LCP is the protocol that has appeared to fill this gap.

Think of a deal between people. The legal record is not something you set out to create; it remains naturally as a byproduct of the interaction. The messages exchanged and the signed contracts stay behind, and there are people who can later testify to what was agreed. Disputes over terms have long been resolvable because the traces needed for proof arose on their own during the course of the transaction.

Once agents begin handling millions of transactions a day at machine speed, however, this premise starts to break down. Records that once remained as a byproduct can diverge between parties, fragment, or get lost. What was routine and recoverable at human scale can turn into a new legal risk as agentic commerce scales the volume of contracts up beyond what is easy to manage.

For example, imagine a company running hundreds of purchasing agents to procure the services it needs automatically. One of those agents buys an AI training dataset from a supplier in India, and the two sides' agents close the deal in seconds without any human review. A few days later it turns out that half the data consists of corrupted files that do not match what was promised, and the moment the company tries to get a refund, awkward questions pour in. Which terms applied to that transaction? Are the terms the agent clicked to accept still the same today, or did the supplier change them afterward? Should the dispute be handled under Indian law or Korean law? And where do you even file a complaint in the first place? All the company holds is a payment record showing that money changed hands, and nowhere is there a record of the conditions under which it changed hands.

LCP seeks to move away from leaving these transaction traces to an unstandardized byproduct, and instead to build them in as a basic element in the design of the transaction itself.

2. How LCP Works

The GitHub repository released alongside the LCP specification contains a JSON schema and example files for each tier, so it is possible to see in fairly concrete detail how the standard is designed to work. This chapter looks in turn at the structure of the discovery document, the point at which verification takes place, and the way LCP can be slotted into other protocols.

2.1 The Structure of the Terms Document

What the standard requires is essentially one thing: that whoever operates a service place a small JSON file at a fixed path under their domain.

The published JSON schema specifies only one required field in this document: terms. It is the absolute address that points to where the terms document lives. The schema forces this value to begin with https://, so that the domain's TLS certificate can serve as a means of identity verification. This makes it possible to follow the same trust model that other files already use, without introducing a separate public key infrastructure.

The idea itself is not new. On the web, robots.txt already announces crawling rules to everyone in the same way, and /.well-known/openid-configuration has long made identity settings discoverable. LCP applies the same approach to legal context, forcing terms that used to be scattered, hidden under /terms, /tos, or inside a separate PDF, to always sit in the same place.

All the remaining fields are optional, and the most complete form included in the repository, the Tier 4 example, shows the range of information the standard can hold.

Source: LCP GitHub

Below is a brief summary of some of the more notable fields the standard carries.

• testFormat: This field tells you in advance what format the terms document uses. For terms meant to be read by agents, it recommends formats a machine can interpret directly, such as Markdown, JSON, or plain text, and advises against layout-oriented formats like PDF or HTML.
• disputeResolution: This covers the clause for resolving transaction disputes. It is meant to include a hash called clauseId, so that anyone can fetch the original clause text from the source address, recompute the hash, and check whether the values match.

2.2 Four Tiers of Trust

LCP lays out four tiers according to the strength of the trust guarantee. Each tier has value on its own, so a service can adopt a given tier without implementing the ones below it.

• Tier 1 (Informational): The terms can be read through a set address. Once an agent finds the terms and proceeds with the transaction, that act itself counts as consent, which simply borrows the familiar legal logic of clickwrap agreements. No hash, signature, or blockchain is required.
• Tier 2 (Provable): A SHA-256 hash of the terms document (atrHash) is published alongside it. This hash pins down exactly what the terms were while also proving that they have not changed. Anyone who downloads the document and computes the hash should get the same value, and a mismatch means the document has been altered. Note that providing a hash requires the terms document to be served identically down to the byte every time, so dynamic rendering that changes content per session is not allowed.
• Tier 3 (Signed): This requires the other party to apply a digital signature to the terms. The code examples cite Ethereum's EIP-712 signatures as one example. At this tier, beyond the terms being provable, you also get cryptographic evidence that a specific party explicitly agreed to specific terms at a specific moment.
• Tier 4 (Integrated): This links out to heavier legal infrastructure such as dispute resolution, escrow, compliance, and private terms. It offers a separate entry point through the api field, and at this tier the terms need not be publicly readable; access can be restricted to authenticated parties only.

2.3 When Verification Happens

LCP clearly separates the moment of verification into a discovery point and a transaction point. The discovery point is the stage where an agent visits legal-context.json to learn how a service handles its terms, and it is purely informational in nature. The transaction point, by contrast, is the moment when the terms must actually be fetched, verified, and stored, and it is at this stage that the hash carries meaning.

As with MCP's 402 challenge, x402's 402 response, and ACP's checkout session creation, every major agentic commerce protocol follows a two-stage flow of proposal and execution. LCP recommends placing the terms hash in the proposal stage rather than on the receipt, because this lets the agent verify the terms before paying. At Tier 2 and above, the procedure an agent follows looks roughly like this:

1. Receive the atrHash (a hash of the entire set of terms) that the server presents in the proposal stage.
2. Download the terms document from the terms address.
3. Compute the SHA-256 hash of the downloaded document yourself.
4. Compare the computed value with the presented atrHash, and stop the transaction if they do not match.
5. Save a local copy of the document.
6. Proceed with payment.
7. Receive a receipt containing the same hash, to confirm afterward what was agreed.

LCP explains that this structure blocks two problems at once: a race condition in which the terms change between the discovery point and the transaction point, an environment where malicious behavior can occur, and a situation in which the server later claims that different terms applied. This works because verification happens at a moment that actually matters, right before payment. At Tier 1 there is no hash to compare against, so an agent has no way to detect changes, but even then LCP recommends saving a copy of the terms seen at the transaction point to keep as evidence.

2.4 Composability with Other Agentic Protocols

Rather than building a new payment network or chain, LCP also defines a reference format that can be slotted into protocols that already exist. Because each protocol carries data differently, LCP does not force a single format but supports several shapes, including strings, hashes, and JSON. In every case it is designed so that the receiving side ignores any field it does not recognize, which allows integration without changing the core specification of the existing protocol.

Here is an example scenario that combines LCP with another protocol.

1. Suppose a user delegates to a purchasing agent the task of buying cloud API access within a set spending limit.
2. The user's delegation is signed as a Cart Mandate under Google's AP2, fixing which items the agent may buy and up to what amount.
3. The agent reaches the seller's server, and the seller's LCP reference is attached to the 402 response that comes just before payment.
4. The agent downloads the terms document, checks the hash, confirms the stated jurisdiction and dispute procedure, leaves consent with a Tier 3 signature if needed, and then proceeds with payment.
5. Once the deal is done, two strands of evidence remain. The AP2 mandate proves what the user approved and whether the agent stayed within that limit, while the LCP record proves which terms the seller put forward and that both sides agreed to them.
6. If delivery later fails and a dispute arises, the authorization protocol's evidence answers whether the agent was properly authorized and acted within its limit, and the LCP evidence answers which terms and jurisdiction the deal fell under and where the dispute should be taken.

The LCP examples also present a delivery method through the Model Context Protocol (MCP). If LCP is implemented as an MCP server, it can expose tools such as get_legal_context to fetch the terms, verify_terms to check that the terms match the published hash, accept_terms to record consent, and initiate_dispute to raise a dispute. In that case, an agent that supports MCP can look up legal context in the same way no matter which payment protocol it transacts through.

3. Implications

3.1 Code Is Not Law

The part of LCP most worth examining is the tension between who leads it and what it says. Integra Ledger, the technical steward, is a blockchain company, yet the standard it built does not make blockchain a required element.

One of crypto's early narratives was the claim that code is law. The vision was that smart contracts would execute automatically and without room for dispute, eventually replacing legal contracts and the human justice system. LCP moves in the opposite direction. Instead of trying to complete enforcement on-chain, it routes machine transactions back to the human legal system and explicitly points to where the jurisdiction, the dispute body, and the remedy can be found. You could sum this up as code being used not to replace law, but to mark the path toward it.

The fact that the AAA, an arbitration body with a hundred years of history, took part as a main pillar of LCP shows this direction well. Crypto long tried to replace trusted intermediaries with code and decentralization, but LCP's design deliberately brings the legal system back in as the last line of defense for resolving disputes. This rests on the premise that the bottleneck in the agent economy is not trustlessness but discoverability and the availability of remedy. No matter how fast agents transact, if the place they ultimately turn to when something goes wrong is a real-world court or arbitration body, then marking a machine-readable path to that place is the more urgent task.

The decision to demote blockchain from a requirement to an option sits in the same context. Hashes, signatures, and on-chain records remain as tools that reinforce trust, but they do not become a barrier to entering the standard. A blockchain company placing its own core technology in a secondary position seems to rest on the view that the biggest obstacle to adopting a legal standard for agents today is not the absence of technology but the complexity of adoption.

This does not mean that LCP rejects blockchain at all. Tier 1, the floor of the standard, requires no chain, but the hashes, signatures, and content-addressed storage used in the tiers above it are things blockchains can provide in a more trustworthy form. The more a service wants to offer higher levels of legal assurance, the more blockchain will come into play.

3.2 The Character of the Participating Chains, and Sui

The official announcement sorts contributors into three groups: enterprise and payment companies such as Google, IBM, Circle, UiPath, and Wayfair; blockchain networks such as Stellar, Avalanche, Cardano, Hedera, Aptos, Sei, and Sui; and finally identity and infrastructure providers such as Crossmint and Pinata.

Most of the blockchain participants are chains aimed at real-world assets, payments, and institutional transactions. Stellar targets cross-border payments, Hedera focuses on enterprise consortium governance, and Sui is pushing toward payments and institutional use. By contrast, Ethereum and Solana, the largest smart contract ecosystems, and the Coinbase camp that leads x402 do not appear on the founding contributor list. Given that LCP's signing example uses Ethereum's EIP-712, Ethereum's absence stands out all the more.

This makeup hints at which side of crypto LCP serves. The chains that gathered are not the trustless DeFi culture built on code is law, but real-world asset and institution-oriented chains that have to convince corporate clients that on-chain transactions lead to enforceable legal agreements in the real world. For them, the absence of a legal layer is not an abstract flaw but a barrier that blocks actual adoption, and LCP can be a tool that lowers it.

Among them, the way Sui participates is especially telling. Meta's Diem project, which can be seen as Sui's prototype, ran aground despite its technical contributions, blocked by regulatory and legal resistance, and the team that lived through that experience has now joined as a founding contributor to a legal-layer standard.

More concretely, the infrastructure Sui has already built or is rolling out overlaps almost exactly with what LCP's upper trust tiers call for. As noted earlier, Tier 2 and above recommend storing the terms document on a content-addressed basis, and Tier 4's private terms require access control and encryption.

Walrus, Mysten Labs' distributed storage protocol, splits large binary files through erasure coding, stores them in a distributed way, and records the reference, a blob ID, on the Sui chain. It generates the storage location identifier deterministically from the content itself, which makes it possible to verify the integrity of that content. This matches the character of the content-addressed storage that LCP proposes as the place to hold terms artifacts.

Seal, also from Mysten Labs, is a threshold encryption tool that uses Move policies to define on-chain who can decrypt data, when, and under what conditions. Its design principle of binding encryption to the data itself rather than to a location runs along the same lines as the approach LCP recommends for private terms, which is to hash the plaintext and then encrypt it. Given that Seal presents agent payments as one of its application examples, Sui can be seen as already holding infrastructure that naturally meshes with LCP's upper tiers on the storage and protection of terms.

For Sui, LCP is less an abstract standard to support from a distance than a discovery and legal layer that sits right on top of the storage and encryption stack it was already building for agentic commerce. Other chains are likely running similar calculations. Even if the standard itself is neutral, the competition over which chain the actual work of storing, encrypting, and anchoring terms takes place on has only just begun.

3.3 Can LCP Become a Standard That Survives?

It is clear that LCP's approach is fresh and addresses a gap in how agentic commerce standards are taking shape, but proposing a good standard and having that standard actually used are entirely different matters. The history of the web holds no small number of standards that were built with good intentions yet barely adopted (HTTP 402 itself is a case in point). So let us weigh, as objectively as possible, the conditions under which LCP would take hold or fade, and gauge its chances of survival.

The conditions in LCP's favor are as follows.

1. The cost of adoption is effectively close to zero. You place a single JSON file at a set path and that is it; using a blockchain is not required, and there are no fees and no sign-up process. As precedents like robots.txt show, a web convention with a low enough entry cost can spread widely even without any mandate.
2. LCP can scale by riding on other protocols. Without laying down its own payment network, it can be used on top of a host protocol such as x402, the Machine Payments Protocol, or ACP, as long as that host accepts a single extension field. Having no competing standard and being easy to integrate into other protocols is clearly an advantage for growth.
3. The problem it tries to solve keeps growing over time. Agentic commerce has not yet scaled to a meaningful size, but as transactions increase, the absence of a legal record will become a pain point. Disputes over the service quality of subscription products, the process of requesting exchanges or refunds for purchased goods, and errors from race conditions during purchase competition between agents are all familiar dispute factors from the Web2 world, and they can arise in the same way in agentic commerce. When such matters escalate into legal disputes, the evidence left in LCP could serve as strong proof.

So what conditions work against LCP?

1. The biggest one is that nothing anywhere forces compliance with LCP. Browsers effectively enforce TLS and crawlers respect robots.txt by convention, but with the terms themselves, no party faces any immediate penalty for failing to post them. A standard that relies only on voluntary judgment, with no enforcement, easily ends up like security.txt in the security field: it exists, but adoption stays uneven.
2. The value of LCP also tends to materialize only in the rare event of a dispute, and even then only after transaction volume has grown. A structure where the cost falls now and the benefit shows up later and only occasionally is hard to sell to adopters, meaning sellers.
3. Finally, there is a risk that host protocols absorb the same function on their own. ACP and UCP already have a terms URL field, so if they chose to, they could implement integrity and consent as their own extension without LCP. On top of that, OpenAI, Stripe, and Coinbase, who hold the largest commerce protocols, are not founding contributors to LCP. If they decided to put a legal layer directly into their own specifications instead of adopting LCP, LCP could lose its place.

So while LCP can reasonably expect a better-than-average level of adoption, active and widespread use seems to depend on a few chokepoints it does not control, namely whether the major commerce protocols and agent runtimes accept it as a default. In my view, this issue can ultimately be resolved if the AAA, an arbitration body with more than a century of practice and a key contributor to LCP, along with the other respected participating institutions, can prove that LCP carries real legal force in an actual dispute.