Part 3: Protocol Extensions
Embed contentHash in existing protocol metadata fields using each protocol's native extension mechanisms.
Part 3 binds terms to transactions at the protocol level. Each payment protocol has its own extension mechanism. ALC uses those mechanisms -- no core spec changes to any protocol.
Protocol Extension Points
| Protocol | Extension Mechanism | contentHash Location |
|---|---|---|
| MPP | opaque field in 402 challenge + TIP-20 memo | 32-byte contentHash in challenge and settlement memo |
| ACP | Checkout session metadata | {"contentHash": "0x..."} in session |
| x402 | Response headers | X-Integra-Hash: 0x... header |
| UCP | Cryptographic mandate metadata | {"contentHash": "0x..."} in mandate |
| AP2 | Mandate metadata | {"integra-evidence-hash": "0x..."} in all three mandates |
| Visa TAP | Agent intent signature payload | contentHash as signed data field |
| A2A | Agent Card extensions + task metadata | "integra" field in agent card; integra-context-hash in tasks |
| MCP | Tool definitions | ALC operations as MCP tools |
| Mastercard | Agentic Token metadata + SD-JWT claims | integra_terms_hash as disclosure |
None of these require changes to the protocol core specification. All use existing extension, metadata, or header mechanisms.
MPP Integration Example
Challenge (server to agent):
The 402 response includes the contentHash in the opaque field. The terms reference travels with the payment challenge.
Settlement (agent pays):
The TIP-20 transfer carries the contentHash in the 32-byte memo field. The terms are now bound to the payment on-chain.
Verification (any party, any time):
Follow the contentHash from the payment memo to the IntegraRecord to the terms document. Verify by hashing.
ACP Integration Example
Checkout session:
{
"session_id": "cs_abc123",
"metadata": {
"contentHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069"
}
}With acceptance required (Tier 2):
Before calling complete_checkout_session, the agent must:
- Fetch terms from the API
- Sign the EIP-712 TermsAcceptance
- Submit the acceptance via
POST /v1/records/{recordId}/accept - Then complete the checkout
What You Get at Part 3
| Capability | Status |
|---|---|
| Document integrity | Yes |
| Machine-discoverable terms | Yes |
| Verification API | Yes |
| Per-transaction terms binding | Yes -- every payment references specific terms |
| Explicit acceptance (Tier 2) | Yes -- EIP-712 signatures before transaction |
| Cross-protocol consistency | Yes -- same contentHash format across all protocols |
| Full dispute resolution | No -- requires Part 4 |
| Escrow / conditional release | No -- requires Part 4 |
| Negotiation | No -- requires Part 4 |
When to Move to Part 4
Part 3 is sufficient for most use cases. Move to Part 4 when you need:
- Automated dispute resolution -- Pre-defined rules for resolving disputes without human intervention
- Escrow management -- Conditional payment release based on deliverable verification
- Negotiation -- Agent-to-agent dynamic terms negotiation (Tier 3)
- Compliance gating -- Regulatory checks before transactions proceed
- Multi-party tokenization -- Complex party structures with multiple principals and agents