The Levels of Trust

One discovery document, four levels of trust.

Adopt as deeply as your use case requires. Each level is independently valuable, and a service can implement any level without implementing the others. Source: LCP §3⁠ (opens in a new tab) The standard itself is one required field at a well-known address; the levels are its advisory guidance on stronger records. Source: LCP §2⁠ (opens in a new tab) · Source: LCP §3⁠ (opens in a new tab)

Sources (2)

LCP §3⁠ (opens in a new tab) · LCP §2⁠ (opens in a new tab)

Level 1

Informational

The terms are published at a known address. Source: LCP §3, Level 1⁠ (opens in a new tab)

An agent can find a service’s terms at one known address on the service’s own website. No hash, no blockchain and no signature is needed. Source: LCP §3, Level 1⁠ (opens in a new tab)

At this level nothing detects a change between discovery and the transaction, so an agent should still fetch and save the terms when it transacts. Source: LCP §5.5⁠ (opens in a new tab)

Sources (2)

LCP §3, Level 1⁠ (opens in a new tab) · LCP §5.5⁠ (opens in a new tab)

The standard

An agent can find a service’s terms: /.well-known/legal-context.json holds one required field, terms, the absolute HTTPS address of a standalone, downloadable terms document. No hash, no blockchain, no signature is needed. Source: LCP §2.4⁠ (opens in a new tab) · Source: LCP §3, Level 1⁠ (opens in a new tab)

At this level nothing detects a change between discovery and the transaction, so an agent should still fetch and save the terms when it transacts. Source: LCP §5.5⁠ (opens in a new tab)

@integraledger/lcp/discovery writes and reads the discovery document: emit writes its members in the standard’s order, and parse checks what LCP §2 states. Source: lcp docs: discovery⁠ (opens in a new tab)

Adds to the discovery document: terms

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The standard’s own example

level-1-minimal.json

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

Check it yourself

Fetch the service’s /.well-known/legal-context.json and read terms: the address of the document an agent must inspect. Source: LCP §2.1⁠ (opens in a new tab)

Level 2

Provable

The terms document has an ATR hash, its unique fingerprint; any change breaks it. Source: LCP §3, Level 2⁠ (opens in a new tab)

The service also publishes the ATR hash of its terms document, the Agentic Transaction Record (ATR). The ATR hash proves what the terms were, and that they have not changed since; the terms must then be served exactly the same every time. Source: LCP §3, Level 2⁠ (opens in a new tab)

Recording when the terms were published, on a chain or with a timestamp service, is optional: the ATR hash alone proves what they say. Source: LCP §3, Level 2⁠ (opens in a new tab)

Sources (1)

LCP §3, Level 2⁠ (opens in a new tab)

The standard

The discovery document adds atrHash, the SHA-256 of the terms document’s exact bytes. It proves what the terms were, and that they have not changed. The document must then be byte-for-byte identical every time it is served. Source: LCP §2.5⁠ (opens in a new tab) · Source: LCP §3, Level 2⁠ (opens in a new tab)

The hash is over the bytes served; nothing is canonicalized first. Anchoring it to a chain, a timestamp authority or content-addressed storage is optional and proves when the terms were published: the hash alone gives provability. Source: LCP §3, Level 2⁠ (opens in a new tab)

The packages carry the same hash per transaction: the seller assembles the ATR for each sale, the buyer’s gate compares the served bytes with the advertised hash before anything is signed, and the payment carries it. Source: lcp docs: the ATR⁠ (opens in a new tab) · Source: lcp docs: the buyer gate⁠ (opens in a new tab)

Adds to the discovery document: atrHash

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The standard’s own example

level-2-provable.json

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

Check it yourself

Hash the terms document’s exact bytes with SHA-256 and compare the digest with atrHash, as 32 bytes. Source: LCP §5.3⁠ (opens in a new tab) · Source: LCP §2.5⁠ (opens in a new tab)

Level 3

Signed

The buyer explicitly accepts that exact document. Source: LCP §3, Level 3⁠ (opens in a new tab)

The buyer signs its acceptance of that exact document: a dated record that a specific party accepted specific terms at a specific time. Source: LCP §3, Level 3⁠ (opens in a new tab)

It is opt-in, for commitments that warrant an attributable record. The standard advises that a buyer’s policy evaluate the terms before any signature is produced, and that a person review commitments above a set threshold. Source: LCP §3, Level 3⁠ (opens in a new tab) · Source: LCP §4⁠ (opens in a new tab)

Sources (2)

LCP §3, Level 3⁠ (opens in a new tab) · LCP §4⁠ (opens in a new tab)

The standard

The client signs the terms, for example with EIP-712 typed data: a timestamped, attributable record that a specific party accepted specific terms at a specific time. acceptanceRequired: true signals that the service wants that explicit acceptance before it transacts. Source: LCP §3, Level 3⁠ (opens in a new tab) · Source: LCP §2.7⁠ (opens in a new tab)

In the published packages, the buyer’s own payment signature carries the ATR hash wherever a pairing allows it: paying is agreeing to that exact ATR. Each pairing’s record says whether the buyer’s signature covers the ATR hash. Source: @integraledger/lcp README⁠ (opens in a new tab) · Source: lcp docs: binding⁠ (opens in a new tab)

Adds to the discovery document: acceptanceRequired

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The standard’s own example

level-3-signed.json

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

Level 4

Integrated

The path to recourse is declared up front. Source: LCP §3, Level 4⁠ (opens in a new tab)

The service declares up front how disputes are resolved, where returns and claims go, and whom to contact. Source: LCP §3, Level 4⁠ (opens in a new tab)

The standard prescribes no enforcement model. A deployment chooses among dispute resolution, pre-settlement verification, escrow, reputation and reconciliation, and more, by the value at stake and the cost of recourse. Source: LCP §3, Level 4⁠ (opens in a new tab)

These entries only point to what the terms say; where they differ, the terms document controls. Source: LCP §2.5⁠ (opens in a new tab)

Sources (2)

LCP §3, Level 4⁠ (opens in a new tab) · LCP §2.5⁠ (opens in a new tab)

The standard

The discovery document adds hooks to richer legal infrastructure: a disputeResolution object (its method, jurisdiction and contact, a content-addressed clause and where to fetch it, a provider’s catalogue), a returns process, contacts, and an api entry point. Source: LCP §2.5⁠ (opens in a new tab) · Source: LCP §3, Level 4⁠ (opens in a new tab)

These fields index what the terms document says; they are not terms themselves. Where a field and the document differ, the document controls. Source: LCP §2.5⁠ (opens in a new tab)

@integraledger/lcp/discovery reads and writes every Level 4 member, and leaves out any member the standard does not define, naming it. Source: lcp docs: discovery⁠ (opens in a new tab)

Adds to the discovery document: disputeResolution, returns, contact, api

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The standard’s own example

level-4-full.json

{
  "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:0xc2eb26d28ff4e229ff35917bd53339d82c1b30ec69435572a8872a4d7609c1dd",
    "source": "https://adr.example.org/clauses/dispute-resolution-service-rules",
    "catalog": "https://adr.example.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/legal-context/v1"
}

Check it yourself

Read disputeResolution: its clauseId names the clause by its content, and source says where to fetch it, so the clause can be fetched and checked against its id. Source: LCP §2.5⁠ (opens in a new tab)

The buyer’s side: policy

The levels describe what a service publishes. A buyer’s policy describes what the buyer will accept: a minimum level, acceptable jurisdictions and dispute methods, caps on what an agent may commit to, and when a person must review before a signature. Source: LCP §4.2⁠ (opens in a new tab)

The policy is evaluated on the buyer’s side, before any signing key is used, over the structured fields rather than the prose an adversary could write. Source: LCP §4.3⁠ (opens in a new tab) · Source: LCP §12.7⁠ (opens in a new tab)

Sources (3)

LCP §4.2⁠ (opens in a new tab) · LCP §4.3⁠ (opens in a new tab) · LCP §12.7⁠ (opens in a new tab)