Terms Binding
How contentHash is embedded in protocol transactions to create provable links between payments and terms.
The contentHash MUST be included in transaction metadata to create a provable link between a payment and the terms that governed it. The specific embedding location depends on the payment protocol.
Protocol Embedding
| Protocol | Embedding Location | Format |
|---|---|---|
| Tempo TIP-20 | memo field (32 bytes) | Raw bytes32 contentHash |
| MPP | Challenge opaque field | Hex-encoded contentHash |
| ACP | Checkout session metadata | {"contentHash": "0x..."} |
| x402 | Response header | X-Integra-Hash: 0x... |
| UCP | Cryptographic mandate metadata | {"contentHash": "0x..."} |
| AP2 | Mandate metadata | {"integra-evidence-hash": "0x..."} |
| Visa TAP | Agent intent signature payload | As signed data field |
| ERC-20/721 | Transaction calldata or event | Emitted in event log |
The contentHash is 32 bytes -- natively compatible with TIP-20 memos, EIP-712 typed data, and payment metadata fields across all protocols. This was a design decision from the Integra reference implementation's pre-agentic era that turned out to be perfectly aligned with the emerging landscape.
Document Integrity
When a vendor creates an on-chain record (IntegraRecord in the reference implementation), the protocol implementation MUST:
- Receive the terms document (via URL fetch or direct upload)
- Store the exact bytes of the document at the moment of receipt (the "snapshot")
- Compute
SHA-256(snapshot)to produce the contentHash - Record the contentHash on-chain via IntegraExistence
- Create the IntegraRecord on-chain with the contentHash and attached resolvers
- Store the snapshot such that it is retrievable via the API
The snapshot is the authoritative copy. The vendor's live URL may change; the snapshot MUST NOT change.
Verification by any party:
- Fetch the snapshot from the API (
GET /v1/records/{recordId}/terms) - Compute
SHA-256(snapshot) - Compare the result to the contentHash (from
legal-context.json, payment memo, or on-chain record) - A match confirms the document is authentic and unchanged
Terms Versioning
When a vendor updates their terms:
- A new snapshot is taken and a new contentHash is computed
- A new IntegraRecord is created (or the existing record is updated with a new contentHash)
- The vendor updates their
legal-context.jsonwith the new contentHash - The previous contentHash remains resolvable -- the API MUST continue to serve historical versions
Transactions reference a specific contentHash. When terms change, new transactions reference the new hash. Old transactions continue to reference the old hash. The version history is available via the API (GET /v1/records/{recordId} returns the versions array).
This creates a complete audit trail: which terms applied to which transactions, provably.