LCPLegal Context Protocol

ACK Integration

Agent Commerce Kit — an LCP reference in the ACK-Pay receipt credential, covered by the issuer's proof.

This section is advisory and non-prescriptive. It describes what the host protocol permits, read from its own primary artifact. Where this page and the host protocol disagree, the host is correct — build from its schema, not from an example here.


Checked against agentcommercekit/ack, packages/ack-pay/src/schemas/valibot.ts, read 2026-09-07.

What it is. An open-source set of patterns and building blocks for agent identity and payments, published by Catena Labs under the MIT licence and built on W3C standards: ACK-ID establishes verifiable agent identity using Decentralized Identifiers and Verifiable Credentials, and ACK-Pay covers payment flows and receipts issued as Verifiable Credentials, with human oversight designed in. It is a reference toolkit rather than a governed standard — it publishes no specification release train, working group, or extension registry.

Tier A — Available today. ACK-Pay issues a PaymentReceiptCredential whose claim carries paymentRequestToken and paymentOptionId alongside an optional, unconstrained metadata object — typed in the reference implementation as an open string-to-unknown record. An LCP reference placed there requires no coordination:

{
  "type": ["VerifiableCredential", "PaymentReceiptCredential"],
  "credentialSubject": {
    "paymentRequestToken": "...",
    "paymentOptionId": "...",
    "metadata": {
      "legalContext": {
        "type": "sha256",
        "value": "0x7f83b165...",
        "legalContextUrl": "https://example.com/atr/k7VdYqZw1uJmH6cnR0aA-g"
      }
    }
  }
}

Because the reference sits inside a Verifiable Credential, it is covered by the issuer's proof — bound to the issuer's assertion rather than merely transported alongside it. This makes ACK one of the few surfaces in this appendix where a Tier A placement is signed by default.

Tier B — Forward work. There is no upstream body to register with. Standardization would take the form of the ACK maintainers documenting a conventional key, which is a documentation act rather than a specification change.

Limitations. The metadata object is optional and unconstrained, so a consumer is not required to read it and different implementations may use different keys for the same idea. ACK publishes patterns and a reference implementation rather than a conformance surface, so "what ACK does" is defined by that implementation rather than by a versioned specification — an integration should be re-checked against the code, not against this illustration.

Steward invitation. Catena Labs is invited to document a conventional legal-context key in the receipt credential's metadata and to publish guidance on the relationship between ACK-ID agent identity and merchant-side terms records.