Categorical Compliance Screening Receipt Format for Agentic-Payment Flows
draft-hopley-x402-compliance-receipt-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | MR CHRISTOPHER HOPLEY | ||
| Last updated | 2026-05-24 (Latest revision 2026-05-23) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hopley-x402-compliance-receipt-01
Independent Submission C. Hopley
Internet-Draft AlgoVoi
Intended status: Informational 30 May 2026
Expires: 1 December 2026
Categorical Compliance Screening Receipt Format for Agentic-Payment
Flows
draft-hopley-x402-compliance-receipt-01
Abstract
This document specifies a categorical compliance screening receipt
format for agentic-payment flows. The format is designed for use by
AI agents and agentic-payment gateways that perform regulatory
screening at admission time and must retain the screening decision
under framework-bound retention obligations (UK Money Laundering
Regulations 2017; Proceeds of Crime Act 2002 Section 330; EU Anti-
Money Laundering Directives 5 and 6; Markets in Crypto-Assets
Regulation Article 80; Anti-Money Laundering Regulation Article 56;
Digital Operational Resilience Act Article 14).
The receipt format uses a closed enumeration of categorical outcomes
(ALLOW, REFER, DENY) rather than a continuous score or tier
projection. The categorical outcome is load-bearing for downstream
regulatory obligations: under UK POCA 2002 Section 330, a REFER
carries a mandatory Suspicious Activity Report obligation that a DENY
does not. A score or tier projection collapses this distinction.
Receipts are canonicalised under RFC 8785 (JSON Canonicalization
Scheme) with an in-band canonicalisation rule pin (canon_version).
The pin enables year-five re-verification from retained bytes alone,
without dependence on an out-of-band rule registry that the operator
must continue to publish.
This document is complementary to draft-vauban-x402-stark-receipts:
that document covers cryptographic settlement-time payment-condition
proofs; this document covers admission-time compliance screening
receipts. The two compose via the composite trust-query algorithm
specified in specs/composite-trust-query.md in x402-foundation/x402.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Hopley Expires 1 December 2026 [Page 1]
Internet-Draft x402-compliance-receipt May 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Relationship to other Internet-Drafts . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Receipt Format Specification . . . . . . . . . . . . . . . . 6
3.1. payer_ref . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. screen_result Closed Enumeration . . . . . . . . . . . . 6
3.3. screen_timestamp_ms . . . . . . . . . . . . . . . . . . . 7
3.4. screen_provider_did . . . . . . . . . . . . . . . . . . . 8
3.5. jurisdiction_flags . . . . . . . . . . . . . . . . . . . 8
3.6. canon_version . . . . . . . . . . . . . . . . . . . . . . 9
4. Canonicalisation . . . . . . . . . . . . . . . . . . . . . . 9
5. Audit Chain Composition . . . . . . . . . . . . . . . . . . . 9
5.1. Chain Row Shape . . . . . . . . . . . . . . . . . . . . . 10
5.2. Linkage Verification . . . . . . . . . . . . . . . . . . 10
5.3. Selective Disclosure . . . . . . . . . . . . . . . . . . 10
5.4. Retention Storage . . . . . . . . . . . . . . . . . . . . 10
Hopley Expires 1 December 2026 [Page 2]
Internet-Draft x402-compliance-receipt May 2026
6. Year-Five Auditability Properties . . . . . . . . . . . . . . 11
7. Composition with Other x402 Substrate . . . . . . . . . . . . 11
7.1. Composite Trust-Query . . . . . . . . . . . . . . . . . . 11
7.2. privacy_class Field . . . . . . . . . . . . . . . . . . . 12
7.3. Compliance Category . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. URN Namespace Registration . . . . . . . . . . . . . . . 12
8.2. Receipt Format Identifier . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Receipt Tampering . . . . . . . . . . . . . . . . . . . . 12
9.2. Chain Truncation and Reordering . . . . . . . . . . . . . 13
9.3. Bundle Forgery . . . . . . . . . . . . . . . . . . . . . 13
9.4. Operator Continuity Loss . . . . . . . . . . . . . . . . 13
9.5. DID Resolution Compromise . . . . . . . . . . . . . . . . 13
9.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 14
A.1. Normative References . . . . . . . . . . . . . . . . . . 14
A.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. Appendix A. Examples (Informative) . . . . . . . . 15
B.1. A.1. ALLOW under UK + EU joint jurisdiction . . . . . . 15
B.2. A.2. REFER under UK with mandatory SAR obligation . . . 15
B.3. A.3. DENY under sanctions match across UK + EU + US . . 16
Appendix C. Appendix B. Reference Implementations
(Informative) . . . . . . . . . . . . . . . . . . . . . . 16
Appendix D. Appendix C. Acknowledgments . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
1.1. Motivation
Agentic-payment flows are payment transactions initiated or routed by
autonomous AI agents acting on behalf of a principal (a natural
person or legal entity). Where these payments cross regulated
payment rails, the payment gateway is obligated to perform compliance
screening at admission time: sanctions screening, anti-money-
laundering checks, and jurisdictional eligibility checks against the
payer and the receiving counterparty.
The output of compliance screening is a categorical decision: either
the payment is allowed to proceed, it is allowed but flagged for
enhanced due diligence and a regulatory report, or it is refused.
This document specifies a receipt format for recording that
categorical decision in a manner suitable for retention under
framework-bound retention obligations.
Hopley Expires 1 December 2026 [Page 3]
Internet-Draft x402-compliance-receipt May 2026
1.2. Scope
In scope:
* The categorical receipt format (Section 3)
* The canonicalisation rule applicable to the receipt (Section 4)
* Audit-chain composition properties (Section 5)
* Year-five auditability properties (Section 6)
* Composition with other x402 substrate specifications (Section 7)
Out of scope:
* The screening algorithm itself. The specific business logic that
produces ALLOW / REFER / DENY (the sanctions feeds consulted, the
anti-money-laundering rules applied, the jurisdictional risk-
scoring methodology) is implementation-defined per screening
provider.
* The retention storage backend. Object Lock COMPLIANCE retention
on S3-compatible storage is recommended (informative, Section 5.4)
but the specific backend is deployment-defined.
* Identity proofing. The payer's identity is referenced through a
content-addressed reference (Section 3.1); how the identity is
established and proofed is the subject of separate work.
1.3. Relationship to other Internet-Drafts
This document is one of a coordinated suite of five AlgoVoi-authored
receipt and response format Internet-Drafts, all anchoring to the
canonicalisation discipline specified in draft-hopley-x402-
canonicalisation-jcs:
* draft-hopley-x402-canonicalisation-jcs -- the JCS canonicalisation
discipline pinned by Section 4 of this document.
* draft-hopley-x402-settlement-attestation -- the per-settlement
categorical attestation format. A compliance receipt admitting a
payment is followed by zero or more settlement attestations on the
audit chain.
* draft-hopley-x402-cancellation-receipt -- the mandate cancellation
receipt format. A compliance receipt admitting a recurring-
payment mandate is followed on the audit chain by a cancellation
receipt when the mandate terminates.
* draft-hopley-x402-refund-receipt -- the post-settlement refund
receipt format.
* draft-hopley-x402-composite-trust-query -- the verifier-side
composite-trust-query response format. A verifier walking an
audit chain composed of compliance, settlement, cancellation, and
refund receipts emits a single composite-trust-query response.
Hopley Expires 1 December 2026 [Page 4]
Internet-Draft x402-compliance-receipt May 2026
The five formats share the same canonicalisation pin, audit-chain row
shape, integer-millisecond timestamp encoding, and content-addressed
reference convention. A verifier walking the full payment lifecycle
requires only one implementation of the canonicalisation discipline.
This document also relates to draft-vauban-x402-stark-receipts
(individual Internet-Draft on the IETF datatracker targeted for the
Independent Submission stream), which covers cryptographic
settlement-time payment-condition proofs using STARK receipts. Both
documents pin the same urn:x402:canonicalisation:jcs-rfc8785-v1
canonicalisation discipline; the two receipt families compose cleanly
via draft-hopley-x402-composite-trust-query.
2. Conventions and Definitions
2.1. Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Definitions
*screening provider*: an entity that performs compliance screening on
an agentic-payment transaction at admission time and emits a
categorical receipt as the screening decision record.
*payer_ref*: a content-addressed reference to the payer's identity.
Typically of the form "sha256:<lowercase-hex>" where the hash is
taken over the JCS-canonical bytes of an identity object held by the
screening provider. The receipt does not carry cleartext identity
content -- only the content-addressed reference -- so the screening
provider's retention layer is GDPR Article 5(1)(c) minimal by
construction.
*screen_result*: the categorical screening outcome. One of ALLOW,
REFER, or DENY. The closed set is load-bearing (Section 3.2).
*screen_timestamp_ms*: an integer giving the number of milliseconds
since the Unix epoch (1970-01-01T00:00:00Z) at which the screening
decision was recorded. See Section 3.3.
*screen_provider_did*: a Decentralised Identifier (DID) identifying
the screening provider. See Section 3.4.
Hopley Expires 1 December 2026 [Page 5]
Internet-Draft x402-compliance-receipt May 2026
*jurisdiction_flags*: an ordered list of regulatory jurisdictions
under which the screening was performed. See Section 3.5.
*canon_version*: an in-band string identifying the canonicalisation
rule under which the receipt was canonicalised. See Section 3.6.
*audit chain*: a monotonic hash-linked sequence of receipts retained
by the screening provider; see Section 5.
3. Receipt Format Specification
A compliance screening receipt is a JSON object containing exactly
the following required fields. Implementations MUST reject receipts
that omit any required field or include fields not listed below.
{
"payer_ref": "<string>",
"screen_result": "<enum: ALLOW | REFER | DENY>",
"screen_timestamp_ms": <integer>,
"screen_provider_did": "<DID URI>",
"jurisdiction_flags": ["<jurisdiction-code>", ...],
"canon_version": "jcs-rfc8785-v1"
}
The JSON Schema (draft-07) for this format is published at
target="https://json.schemastore.org/algovoi-compliance-receipt-
v1.json" (https://json.schemastore.org/algovoi-compliance-receipt-
v1.json).
3.1. payer_ref
The payer_ref field MUST be a non-empty string identifying the payer
by content-addressed reference. The recommended form is
"sha256:<lowercase-hex>" where the hex is the lowercase hexadecimal
representation of the SHA-256 digest of the JCS-canonical bytes of
the underlying identity object.
The receipt MUST NOT carry cleartext identity content. This ensures
that the screening provider's retention layer is GDPR Article 5(1)(c)
minimal by construction; identity content can be re-presented to the
receipt holder out-of-band when necessary.
3.2. screen_result Closed Enumeration
The screen_result field MUST be exactly one of the following three
string values:
Hopley Expires 1 December 2026 [Page 6]
Internet-Draft x402-compliance-receipt May 2026
+=======+===================================================+
| Value | Meaning |
+=======+===================================================+
| ALLOW | The transaction is cleared to proceed under the |
| | regulatory gate at the screening provider's |
| | jurisdictions. |
+-------+---------------------------------------------------+
| REFER | The transaction is flagged for enhanced due |
| | diligence. Depending on the screening provider's |
| | jurisdictions (jurisdiction_flags) this MAY |
| | trigger a mandatory Suspicious Activity Report or |
| | equivalent regulatory filing obligation. |
+-------+---------------------------------------------------+
| DENY | The transaction is refused under a sanctions or |
| | anti-money-laundering rule. |
+-------+---------------------------------------------------+
Table 1
The closed three-value enumeration is load-bearing. Under UK
Proceeds of Crime Act 2002 Section 330, a REFER outcome triggers a
mandatory Suspicious Activity Report obligation to the UK National
Crime Agency for institutions in the regulated sector. A DENY
outcome does not trigger the same obligation: it refuses the
transaction but does not by itself require a SAR.
A receipt format that compresses screen_result to a continuous score
or to a coarser tier set (e.g. "high / medium / low") loses this
load-bearing distinction. A year-five auditor reading a retained
receipt under such a projection cannot determine, from the retained
bytes alone, whether the historical decision triggered a mandatory
regulatory report. This document REQUIRES the closed three-value
enumeration for that reason.
Future extensions to the receipt format MAY add additional fields
alongside the categorical screen_result (e.g. a continuous score for
internal monitoring use), but MUST NOT remove or alter the closed
enumeration on screen_result itself.
3.3. screen_timestamp_ms
The screen_timestamp_ms field MUST be a non-negative integer giving
the number of milliseconds elapsed since 1970-01-01T00:00:00Z (Unix
epoch).
Hopley Expires 1 December 2026 [Page 7]
Internet-Draft x402-compliance-receipt May 2026
The field MUST NOT be a floating-point number, MUST NOT be a JSON-
formatted string, and MUST NOT be in RFC 3339 ISO-8601 format.
Implementations that receive a non-integer value MUST reject the
receipt at the validation layer before canonicalisation; silent type-
cast from float to integer is forbidden.
The integer-only restriction is required because RFC 8785
canonicalises floating-point numbers and integers differently. A
receipt whose timestamp was emitted as an integer and later re-
canonicalised after a type-cast from float would produce different
canonical bytes and a different content_hash -- which would fail the
year-five auditability property (Section 6).
3.4. screen_provider_did
The screen_provider_did field MUST be a Decentralised Identifier
(DID) URI conforming to the DID syntax: "did:" followed by one or
more alphanumeric characters identifying the DID method, followed by
a method-specific identifier.
Implementations MAY use any DID method, including but not limited to
did:web, did:key, did:ion, did:peer. The did:web method is
RECOMMENDED where the screening provider operates a stable HTTPS-
resolvable endpoint, because did:web allows verifiers to retrieve the
screening provider's public key directly from a well-known URI
without consulting any external registry.
3.5. jurisdiction_flags
The jurisdiction_flags field MUST be a non-empty JSON array of
strings. Each string identifies a regulatory jurisdiction under
which the screening was performed.
Recommended values follow ISO 3166-1 alpha-2 country codes (e.g.
"UK", "DE", "JP"). Aggregate jurisdiction codes such as "EU" MAY
also be used.
The array element ORDER is SIGNIFICANT and load-bearing. RFC 8785
Section 3.2.3 specifies that JSON array element order is preserved
during canonicalisation. The array ["UK", "EU"] and the array ["EU",
"UK"] therefore canonicalise to different bytes and produce different
content_hash values.
Producer-side ordering MUST match the order in which the regulatory
rules were applied. Verifiers SHOULD validate ordering consistency
across a screening provider's retained chain.
Hopley Expires 1 December 2026 [Page 8]
Internet-Draft x402-compliance-receipt May 2026
3.6. canon_version
The canon_version field MUST be the string "jcs-rfc8785-v1" for
receipts emitted under the canonicalisation discipline specified by
this version of this document.
Future revisions of the canonicalisation discipline MAY introduce
successor pin values ("jcs-rfc8785-v2", etc.). Implementations re-
canonicalising a retained receipt MUST consult the receipt's
canon_version field and apply the corresponding canonicalisation
rule.
The in-band pin enables year-five re-verification: the rule active at
emission is recorded in the retained bytes themselves and does not
require an out-of-band rule registry that the screening provider must
continue to publish.
4. Canonicalisation
Compliance receipts are canonicalised using JSON Canonicalization
Scheme (JCS) as specified in [RFC8785]. The canonicalisation
discipline applicable to this document is identified by the URN:
urn:x402:canonicalisation:jcs-rfc8785-v1
The discipline imposes the following rules on receipt content:
* RFC 8785 canonical JSON for the receipt object.
* Object keys are sorted lexicographically by Unicode code-point
order (per RFC 8785 Section 3.2.3).
* Array element order is preserved (per RFC 8785 Section 3.2.3).
* Numeric values are canonicalised per RFC 8785 Section 3.2.2.3.
* The integer-only restriction on screen_timestamp_ms (Section 3.3)
is applied at the validation layer before canonicalisation.
The discipline applies to:
* The receipt object itself, for computation of the content_hash
(Section 5).
* The bundle of receipts emitted as a selective-disclosure audit
bundle (out of scope for this document; see related work in
Section 5.4).
5. Audit Chain Composition
A screening provider that emits compliance receipts under this format
SHOULD compose those receipts into a monotonic hash-linked audit
chain.
Hopley Expires 1 December 2026 [Page 9]
Internet-Draft x402-compliance-receipt May 2026
5.1. Chain Row Shape
Each row in the audit chain MUST carry the following three fields in
addition to the receipt itself:
* chain_position: a non-negative integer that increases
monotonically with each new row, starting at zero for the chain
head.
* content_hash: the lowercase hexadecimal SHA-256 hash of the JCS-
canonical bytes of the receipt object.
* prev_hash: the content_hash of the previous chain row, or null for
the chain head (chain_position = 0).
5.2. Linkage Verification
A verifier walking the chain MUST confirm:
* chain_position increases by exactly one between successive rows.
* prev_hash on row N equals content_hash on row (N - 1).
* content_hash on each row recomputes to SHA-
256(JCS(receipt_object)) from the retained bytes.
Any linkage break MUST cause the verifier to reject the chain.
5.3. Selective Disclosure
A screening provider MAY emit a selective-disclosure audit bundle
containing a subset of the retained chain (typically filtered by a
selection_criteria such as tenant_id, payer_ref, screen_result, or a
time range). Such bundles MAY include "bridging_rows" that fill
chain gaps between selected rows so that the verifier can confirm
linkage continuity across the disclosed subset.
The specific bundle envelope format is out of scope for this
document. A reference implementation of the selective-disclosure
bundle format and the corresponding verifier is published at
target="https://github.com/chopmob-cloud/algovoi-audit-verifier"
(https://github.com/chopmob-cloud/algovoi-audit-verifier) (MIT
licensed).
5.4. Retention Storage
The retention storage backend for the chain is out of scope for this
document. An S3-compatible Object Lock COMPLIANCE retention is
RECOMMENDED where the screening provider is subject to retention
obligations of seven years or more (e.g. UK MLR 2017 Regulation
40(3)).
Hopley Expires 1 December 2026 [Page 10]
Internet-Draft x402-compliance-receipt May 2026
6. Year-Five Auditability Properties
This receipt format is designed to satisfy the following auditability
properties:
1. *Re-verification from retained bytes alone.* A year-five verifier
reading a retained chain can recompute every content_hash from
the row's payload and confirm linkage against prev_hash without
consulting any external service. The in-band canon_version pin
identifies which canonicalisation rule to apply.
2. *Operator-continuity independence.* Verification does NOT require
the screening provider to continue to publish a canonicalisation
rule registry, a sanctions feed snapshot, or any other out-of-
band resource. The receipt is self-contained.
3. *Cross-implementation verifiability.* The JCS RFC 8785
canonicalisation discipline has been byte-for-byte cross-
validated across multiple independent reference implementations
including Python rfc8785, JavaScript canonicalize, Go gowebpki/
jcs, Java cyberphone/json-canonicalization, and Rust serde_jcs.
A verifier built with any of these implementations produces
identical canonical bytes for any compliance receipt under this
format.
4. *Tamper detection.* Per-row content_hash and chain prev_hash
linkage detect single-row tampering and chain truncation /
reordering respectively.
5. *Regulatory distinction preserved.* The closed enumeration on
screen_result (Section 3.2) preserves the load-bearing
distinction between REFER (mandatory SAR under UK POCA 2002
s.330) and DENY for the full retention period.
7. Composition with Other x402 Substrate
This receipt format composes with other elements of the x402
substrate:
7.1. Composite Trust-Query
Multiple emitters' attestations -- including compliance receipts
under this format, STARK payment-condition receipts under draft-
vauban-x402-stark-receipts, and service-reputation receipts from
other providers -- compose into a single canonical composite_hash via
the composite trust-query algorithm specified in specs/composite-
trust-query.md (in x402-foundation/x402 pull request #2440):
Hopley Expires 1 December 2026 [Page 11]
Internet-Draft x402-compliance-receipt May 2026
composite_hash = SHA-256(JCS([rows sorted by source_id, sig
excluded]))
A downstream verifier consuming a composite_hash sees one emitter row
per provider, each row containing or referencing the JCS-canonical
bytes of the provider's underlying receipt.
7.2. privacy_class Field
A receipt MAY carry an additional privacy_class field (per the x402-
foundation/x402 pull request #2334) declaring the settlement-plane
visibility of the receipt. The field is not part of the required-
fields set of this document but is interoperable with it.
7.3. Compliance Category
This receipt format is one of the evidenceShape options under the
Compliance evidenceType category proposed in x402-foundation/x402
pull request #2322. The Compliance category framework provides the
broader extension mechanism by which Bazaar registries may surface
compliance attestations.
8. IANA Considerations
8.1. URN Namespace Registration
This document requests IANA register the following URN namespace per
the procedures of [RFC8141]:
* URN namespace: urn:x402:canonicalisation:jcs-rfc8785-v1
* Purpose: identifies the JCS RFC 8785 canonicalisation discipline
applied to receipts under this document and companion documents.
8.2. Receipt Format Identifier
This document does not request the registration of a new media type.
Receipts under this format use the application/json media type with
the structural constraints specified in Section 3.
9. Security Considerations
9.1. Receipt Tampering
The per-row content_hash provides single-row tamper detection. A
verifier recomputing content_hash from the receipt's JCS-canonical
bytes detects any modification to the receipt content (including
modification to a single field, byte, or whitespace).
Hopley Expires 1 December 2026 [Page 12]
Internet-Draft x402-compliance-receipt May 2026
9.2. Chain Truncation and Reordering
The prev_hash linkage detects chain truncation, row removal, and
reordering. A verifier walking the chain confirms that prev_hash on
each row equals content_hash on the previous row; any break in the
walk indicates tampering, truncation, or reordering.
9.3. Bundle Forgery
A screening provider MAY sign a selective-disclosure audit bundle
with an HMAC-SHA256 over the JCS-canonical bytes of the bundle (minus
the signature field). The shared signing key is the proof-of-
emission secret; verifiers possessing the key can confirm that the
bundle was emitted by the holder of the key.
This document does not REQUIRE bundle signing -- the per-row content
hashes and chain linkage already provide tamper detection -- but it
RECOMMENDS bundle signing for selective-disclosure exchanges where
the verifier must distinguish "bundle emitted by the screening
provider" from "bundle reconstructed from elsewhere."
9.4. Operator Continuity Loss
The in-band canon_version pin (Section 3.6) ensures that re-
verification does not require operator continuity. If the screening
provider ceases operations, retained chains remain verifiable: the
rule named by canon_version is publicly documented and stable.
9.5. DID Resolution Compromise
The screen_provider_did is a Decentralised Identifier. Verifiers
SHOULD resolve it through multiple resolvers (where the DID method
supports multi-resolver patterns) and confirm consistency before
accepting public key material for signature verification on
selective-disclosure bundles.
9.6. Privacy
The payer_ref content-addressed reference does not by itself leak
identity content. A receipt holder presenting the receipt out-of-
band can also present the underlying identity object; the receipt
holder chooses when and to whom to disclose identity. This is the
selective-disclosure pattern that justifies the content-addressed
reference design.
Hopley Expires 1 December 2026 [Page 13]
Internet-Draft x402-compliance-receipt May 2026
Implementations MUST NOT log cleartext identity content alongside
receipts in the chain. Implementations MUST NOT recover the
underlying identity object from payer_ref alone -- the reference is a
one-way hash.
Appendix A. References
A.1. Normative References
* [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997.
* [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
* [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON)
Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259,
December 2017.
* [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785,
June 2020.
* [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017.
A.2. Informative References
* draft-hopley-x402-canonicalisation-jcs Hopley, C., "JCS
Canonicalisation Discipline for Agentic-Payment Receipts", draft-
hopley-x402-canonicalisation-jcs-v1, May 2026.
* draft-hopley-x402-settlement-attestation Hopley, C., "Categorical
Settlement Attestation Format for Agentic-Payment Flows", draft-
hopley-x402-settlement-attestation-00, May 2026.
* draft-hopley-x402-cancellation-receipt Hopley, C., "Categorical
Mandate Cancellation Receipt Format for Agentic-Payment Flows",
draft-hopley-x402-cancellation-receipt-00, May 2026.
* draft-hopley-x402-refund-receipt Hopley, C., "Categorical Refund
Receipt Format for Agentic-Payment Flows", draft-hopley-x402-
refund-receipt-00, May 2026.
* draft-hopley-x402-composite-trust-query Hopley, C., "Composite
Trust Query Response Format for Agentic-Payment Audit Chains",
draft-hopley-x402-composite-trust-query-00, May 2026.
* draft-vauban-x402-stark-receipts draft-vauban-x402-stark-receipts
(companion document on STARK receipt format).
* [AlgoVoi-Substrate-Authorship] AlgoVoi, "Substrate Authorship and
Provenance", target="https://docs.algovoi.co.uk/substrate-
authorship-provenance" (https://docs.algovoi.co.uk/substrate-
authorship-provenance)
Hopley Expires 1 December 2026 [Page 14]
Internet-Draft x402-compliance-receipt May 2026
* [AlgoVoi-Adopters-Registry] AlgoVoi, "Substrate Adopters
Registry", target="https://docs.algovoi.co.uk/adopters"
(https://docs.algovoi.co.uk/adopters)
* x402-foundation/x402 pull request #2440 -- composite trust-query
algorithm.
* x402-foundation/x402 pull request #2334 -- privacy_class field.
* x402-foundation/x402 pull request #2322 -- Compliance category
proposal with evidenceType, evidenceShape, anchor_chains
constraint.
* x402-foundation/x402 pull request #2434 -- compliance-receipt-
fixture (the reference fixture for this receipt format in the x402
Foundation conformance suite).
* UK Money Laundering Regulations 2017.
* UK Proceeds of Crime Act 2002, Section 330.
* EU Anti-Money Laundering Directive 5 (Directive (EU) 2018/843).
* EU Anti-Money Laundering Directive 6 (Directive (EU) 2018/1673).
* EU Markets in Crypto-Assets Regulation (MiCA, Regulation (EU)
2023/1114), Article 80.
* EU Anti-Money Laundering Regulation (AMLR, Regulation (EU)
2024/1624), Article 56.
* EU Digital Operational Resilience Act (DORA, Regulation (EU)
2022/2554), Article 14.
Appendix B. Appendix A. Examples (Informative)
The following example receipts illustrate the format. All three are
syntactically valid under the JSON Schema at
target="https://json.schemastore.org/algovoi-compliance-receipt-
v1.json" (https://json.schemastore.org/algovoi-compliance-receipt-
v1.json).
B.1. A.1. ALLOW under UK + EU joint jurisdiction
{
"payer_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
"screen_result": "ALLOW",
"screen_timestamp_ms": 1716460800000,
"screen_provider_did": "did:web:api.algovoi.co.uk",
"jurisdiction_flags": ["UK", "EU"],
"canon_version": "jcs-rfc8785-v1"
}
B.2. A.2. REFER under UK with mandatory SAR obligation
Hopley Expires 1 December 2026 [Page 15]
Internet-Draft x402-compliance-receipt May 2026
{
"payer_ref": "sha256:4b781b0d3f8a82c5e6e91077928d3c9156b1ab51c19d7eef03f1d2956b1a3e72",
"screen_result": "REFER",
"screen_timestamp_ms": 1716460800050,
"screen_provider_did": "did:web:api.algovoi.co.uk",
"jurisdiction_flags": ["UK"],
"canon_version": "jcs-rfc8785-v1"
}
Per Section 3.2: institutions in the regulated sector emitting a
REFER under a UK jurisdiction MUST file a SAR with the UK National
Crime Agency per UK POCA 2002 Section 330.
B.3. A.3. DENY under sanctions match across UK + EU + US
{
"payer_ref": "sha256:10779e0aeb2e1d3aa2c419c91d1e0cd0c14d9a8a3f6c2f25b3d0aa1075c3e438",
"screen_result": "DENY",
"screen_timestamp_ms": 1716460800100,
"screen_provider_did": "did:web:api.algovoi.co.uk",
"jurisdiction_flags": ["UK", "EU", "US"],
"canon_version": "jcs-rfc8785-v1"
}
Appendix C. Appendix B. Reference Implementations (Informative)
The following open-source packages implement the format specified in
this document. None of these implementations is privileged; the
format is fully specified by Section 3.
* algovoi-substrate (Python) on PyPI:
target="https://pypi.org/project/algovoi-substrate/"
(https://pypi.org/project/algovoi-substrate/) Provides
build_compliance_receipt(), action_ref(), and the JCS
canonicalisation primitive. Apache 2.0 licensed.
* @algovoi/substrate (TypeScript) on npm:
target="https://www.npmjs.com/package/@algovoi/substrate"
(https://www.npmjs.com/package/@algovoi/substrate) Byte-for-byte
parity with the Python sibling. Apache 2.0 licensed.
* algovoi-audit-verifier (Python) on PyPI:
target="https://pypi.org/project/algovoi-audit-verifier/"
(https://pypi.org/project/algovoi-audit-verifier/) Implements the
audit-chain verification logic (Section 5.2) including per-row
content_hash recomputation and chain linkage walk. MIT licensed.
Hopley Expires 1 December 2026 [Page 16]
Internet-Draft x402-compliance-receipt May 2026
* @algovoi/audit-verifier (TypeScript) on npm:
target="https://www.npmjs.com/package/@algovoi/audit-verifier"
(https://www.npmjs.com/package/@algovoi/audit-verifier) Byte-for-
byte parity with the Python verifier. MIT licensed.
Cross-implementation conformance vectors are published at:
target="https://github.com/chopmob-cloud/algovoi-jcs-conformance-
vectors" (https://github.com/chopmob-cloud/algovoi-jcs-conformance-
vectors)
The JSON Schema (draft-07) at target="https://json.schemastore.org/
algovoi-compliance-receipt-v1.json" (https://json.schemastore.org/
algovoi-compliance-receipt-v1.json) is mirrored at the same
repository.
Appendix D. Appendix C. Acknowledgments
This document builds on the canonicalisation discipline formalised in
x402-foundation/x402 pull request #2436, co-signed by the document
author with seritalien (Vauban Pay) and arian-gogani (Arian Gogani).
The framework-bound-retention scoping clause in the discipline was
contributed by feedoracle (FeedOracle). The receipt-format fixture
in x402-foundation/x402 pull request #2434 was authored by seritalien
(Vauban Pay) and explicitly references the AlgoVoi production schema
as its source.
Author's Address
Christopher Hopley
AlgoVoi
Email: chopmob@gmail.com
Hopley Expires 1 December 2026 [Page 17]