The Solution -- legal-context.json

The Agent Legal Context (ALC) protocol is not a terms management system. It does not tell vendors how to write, publish, or format their terms. ALC provides two things:

1. Record the proof that specific terms existed at a specific moment in time
2. Make that proof referenceable in transactions

The standard defines how this proof gets discovered and accessed -- not through blockchain queries, but through a simple API that bridges the agent world (HTTP/JSON) to the on-chain world (smart contracts, resolvers).

The Entry Point: /.well-known/legal-context.json

A vendor publishes a well-known endpoint -- like robots.txt or /.well-known/acp.json -- that provides the minimum an agent needs:

{
  "version": "1.0",
  "contentHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
  "api": "https://api.integraledger.net/v1/records/0xabcdef1234567890"
}

Three fields that matter:

• contentHash -- The SHA-256 hash of the current terms document. The proof anchor. (The field name contentHash follows the Integra reference implementation convention.)
• api -- An ALC API endpoint where the agent can get everything else.
• acceptanceRequired (optional) -- Does the agent need to explicitly accept (Tier 2), or is transacting sufficient (Tier 1)?

The legal-context.json file is the entry point. The API is the gateway.

The API Gateway

The API endpoint is where all the resolver functionality lives -- but the agent just sees HTTP/JSON. No web3 libraries, no RPC providers, no chain knowledge. It makes HTTP calls. The API does the on-chain work. The Integra reference implementation hosts one such gateway at api.integraledger.net; anyone can self-host or use a third-party provider.

What the agent can do:

Three Things It Enables

Discover

Any agent fetches /.well-known/legal-context.json from a vendor's domain. In one HTTP call, it knows:

• The hash of the current terms
• Where to verify and interact with those terms
• Whether explicit acceptance is required

Verify

Any party can verify document authenticity:

1. Fetch the terms from the API
2. Compute SHA-256(document)
3. Compare to the contentHash
4. Match confirms the document is authentic and unchanged

One API call to verify. No blockchain interaction needed. The on-chain record is the ultimate backstop, but the API makes verification accessible to any HTTP client.

Interact

Agents accept terms, file disputes, and retrieve contact information through the same API. The resolvers behind the API handle the domain-specific logic -- one vendor has simple terms and a refund policy, another has escrow conditions and AAA arbitration. The agent does not care. It calls the same endpoints.

Document Integrity: The Snapshot Model

When a vendor creates a record (called IntegraRecord in the reference implementation), the protocol snapshots the exact bytes of the terms document at that moment. The snapshot is what gets hashed. The snapshot is what the API returns.

The vendor's live URL may change. The snapshot never changes. Any party can verify document authenticity by comparing the API response to the on-chain hash.

Vendor setup flow:

1. Vendor provides their terms (URL or file upload) to the ALC API
2. The API fetches the document and stores the exact bytes
3. SHA-256(snapshot) produces the contentHash
4. An on-chain record is created with the hash and resolvers
5. Vendor gets back the contentHash and API URL to put in their legal-context.json

Verification flow:

1. Fetch the terms document from the API
2. Hash the response body
3. Compare to the contentHash (from legal-context.json, payment memo, or on-chain record)
4. Match = authentic and unchanged

Three Hosting Models

The API can be hosted by anyone. The standard defines the interface -- endpoints, schemas, error codes. The implementation is anyone's to run.

The API URL in legal-context.json is the only difference visible to clients. All three models serve the same endpoints with the same response schemas.

Discovery Contexts

For websites and APIs -- /.well-known/legal-context.json endpoint. Any HTTP client discovers the terms entry point.

For AI agents -- When an agent advertises itself (A2A Agent Cards, MCP tool manifests, ACP discovery), it includes its ALC metadata:

{
  "name": "Acme Compute Agent",
  "capabilities": ["compute", "inference"],
  "integra": {
    "contentHash": "0x7f83b165...",
    "api": "https://api.integraledger.net/v1/records/0xabcdef..."
  }
}

The "integra" key name in agent metadata follows the Integra reference implementation convention.

For payment protocols -- The contentHash in MPP challenges, ACP sessions, x402 headers, or TIP-20 memos is the per-transaction binding. The API is the resolution mechanism.

Next Steps

• Specification -- The full protocol specification
• Getting Started -- Four-part adoption staircase
• Protocol Landscape -- How ALC integrates with every major protocol