Examples

These examples illustrate legal-context.json at each level of trust assurance.

Minimal (Level 1)

The simplest valid configuration. A URL to the terms document. This is all that is required.

{
  "terms": "https://example.com/terms/v3.md"
}

An agent discovering this file knows where to find the terms. Proceeding with a transaction after discovering the terms constitutes affirmative consent — consistent with the legal framework for browsewrap/clickwrap agreements under U.S. law (UETA § 14, E-SIGN) and EU law (E-Commerce Directive 2000/31/EC, eIDAS).

With ATR Hash (Level 2)

Adding a atrHash makes the terms provable. Any party can download the document, compute SHA-256, and verify the hash matches.

{
  "terms": "https://example.com/terms/v3.md",
  "atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069"
}

The hash proves what the terms were and that they have not changed. No blockchain or third-party service required — the hash alone provides provability.

With Signed Acceptance (Level 3)

Adding acceptanceRequired: true signals that counterparties must digitally sign the terms before transacting — for example, using EIP-712 typed data signing. This creates cryptographic proof that a specific party explicitly consented to specific terms at a specific time.

{
  "terms": "https://example.com/terms/v3.md",
  "atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
  "acceptanceRequired": true
}

This is the digital equivalent of a signed contract. The signature binds an identity to a document. The atrHash proves what was agreed; the signature proves who agreed and when.

Full (Level 4)

A complete configuration with dispute resolution, contact information, and an API endpoint for richer legal infrastructure.

{
  "terms": "https://example.com/terms/v3.json",
  "termsFormat": "json",
  "atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
  "acceptanceRequired": true,
  "disputeResolution": {
    "method": "Dispute Resolution Service Rules",
    "jurisdiction": "New York, USA",
    "contact": "disputes@example.com",
    "clauseId": "sha256:0x<hash>",
    "source": "https://www.{dispute_resolution_service}.org/clauses/commercial-arbitration",
    "catalog": "https://www.{dispute_resolution_service}.org/.well-known/dispute-services.json"
  },
  "returns": "https://example.com/api/returns",
  "contact": {
    "legal": "legal@example.com",
    "technical": "api-support@example.com"
  },
  "api": "https://api.example.com/v1/records/0xabcdef1234567890"
}

At this level, the legal context includes:

• Machine-readable terms — termsFormat signals the terms document is structured data an agent can parse
• Provable terms — the ATR hash identifies the exact document
• Explicit acceptance required — counterparties must sign before transacting
• Verifiable dispute resolution — the clauseId identifies the exact clause by hash; the source URL lets agents retrieve and verify it; the catalog URL provides the provider's full service menu
• Returns process — a dedicated API endpoint
• Contact information — separate legal and technical contacts
• API endpoint — entry point to a full legal context API (record management, verification, dispute filing)

The api field is the bridge from the open standard to any implementation that provides richer legal infrastructure. The standard does not endorse or canonize any particular implementation; the api field is the hook from the standard to whichever legal infrastructure a deployment selects.