Categorical Settlement Attestation Format for Agentic-Payment Flows
draft-hopley-x402-settlement-attestation-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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | MR CHRISTOPHER HOPLEY | ||
| Last updated | 2026-05-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-settlement-attestation-01
Independent Submission C. Hopley
Internet-Draft AlgoVoi
Intended status: Informational 30 May 2026
Expires: 1 December 2026
Categorical Settlement Attestation Format for Agentic-Payment Flows
draft-hopley-x402-settlement-attestation-01
Abstract
This document specifies a categorical settlement attestation format
for agentic-payment flows. The format records that a payment has
reached a particular settlement state on a particular chain, at a
particular instant, under the attesting party's risk model.
The receipt format uses a closed enumeration of categorical outcomes
(SETTLED, PENDING_FINALITY, REVERSED). The categorical outcome is
load-bearing for downstream regulatory obligations: SETTLED triggers
settlement-finality record-keeping obligations under EU Markets in
Crypto-Assets Regulation Article 80 and Anti-Money Laundering
Regulation Article 56; the PSD2 (Directive 2015/2366) Article 89
unauthorised-payment refund-window clock begins at SETTLED.
PENDING_FINALITY records an inclusion-without-finality state where
the refund-window has not yet started. REVERSED records chain-
reorganisation, fraud-reversal, or operator-initiated reversal events
for chain-of-custody audit.
The format is multi-chain: a single settlement_chain string field
identifies the chain on which settlement occurred, using a flat
identifier convention (<chain_family> for default mainnets,
<chain_family>:<network> for non-default networks). The receipt does
not encode chain-specific finality semantics; those are applied at
verification time by a verifier that knows the chain.
The format composes with the AlgoVoi-authored compliance receipt
format (draft-hopley-x402-compliance-receipt) and refund receipt
format (draft-hopley-x402-refund-receipt) under the same
canonicalisation discipline (draft-hopley-x402-canonicalisation-jcs).
A verifier walking the audit chain confirms the full payment
lifecycle from admission through settlement to refund (or non-refund)
under one byte-deterministic canonicalisation pin.
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-settlement-attestation 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 . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Receipt Format Specification . . . . . . . . . . . . . . . . 6
3.1. settlement_result . . . . . . . . . . . . . . . . . . . . 6
3.2. jurisdiction_flags . . . . . . . . . . . . . . . . . . . 7
3.3. settled_payment_ref . . . . . . . . . . . . . . . . . . . 7
3.4. settlement_amount . . . . . . . . . . . . . . . . . . . . 7
3.5. settlement_chain . . . . . . . . . . . . . . . . . . . . 8
3.6. settlement_provider_did . . . . . . . . . . . . . . . . . 9
3.7. settlement_timestamp_ms . . . . . . . . . . . . . . . . . 9
3.8. canon_version . . . . . . . . . . . . . . . . . . . . . . 9
4. Canonicalisation . . . . . . . . . . . . . . . . . . . . . . 9
5. Audit Chain Composition . . . . . . . . . . . . . . . . . . . 9
5.1. Chain Row Shape . . . . . . . . . . . . . . . . . . . . . 10
5.2. Linkage Verification . . . . . . . . . . . . . . . . . . 10
Hopley Expires 1 December 2026 [Page 2]
Internet-Draft x402-settlement-attestation May 2026
5.3. Composition with Compliance Receipts . . . . . . . . . . 10
5.4. Composition with Refund Receipts . . . . . . . . . . . . 10
6. Year-N Auditability Properties . . . . . . . . . . . . . . . 11
7. Composition with Other x402 Substrate . . . . . . . . . . . . 11
7.1. Compliance Receipt Linkage . . . . . . . . . . . . . . . 11
7.2. Refund Receipt Linkage . . . . . . . . . . . . . . . . . 11
7.3. Cryptographic Settlement Proofs . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. URN Namespace Registration . . . . . . . . . . . . . . . 12
8.2. Receipt Format Identifier . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Attestation Tampering . . . . . . . . . . . . . . . . . . 12
9.2. Chain Reorganisation . . . . . . . . . . . . . . . . . . 13
9.3. Chain Identifier Spoofing . . . . . . . . . . . . . . . . 13
9.4. Cross-Asset Substitution . . . . . . . . . . . . . . . . 13
9.5. Operator Continuity Loss . . . . . . . . . . . . . . . . 13
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 13
A.1. Normative References . . . . . . . . . . . . . . . . . . 13
A.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. Appendix A. Examples (Informative) . . . . . . . . 14
B.1. A.1. SETTLED on Base under UK + EU joint jurisdiction . 14
B.2. A.2. PENDING_FINALITY on Algorand . . . . . . . . . . . 15
B.3. A.3. REVERSED on Ethereum mainnet after chain reorg . . 15
Appendix C. Appendix B. Reference Implementations
(Informative) . . . . . . . . . . . . . . . . . . . . . . 15
Appendix D. Appendix C. Acknowledgments . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
1.1. Motivation
Agentic-payment flows generate three classes of categorical receipt
across the payment lifecycle:
1. Admission-time receipts (compliance screening, payment
authorisation, mandate verification).
2. Settlement-time receipts (this document).
3. Post-settlement receipts (refund, dispute resolution).
Settlement is the state transition at which a broadcast payment is
considered final by the attesting party's risk model. The
operational and regulatory significance is load-bearing:
Hopley Expires 1 December 2026 [Page 3]
Internet-Draft x402-settlement-attestation May 2026
* Under EU Markets in Crypto-Assets Regulation Article 80
(Regulation (EU) 2023/1114) and EU Anti-Money Laundering
Regulation Article 56 (Regulation (EU) 2024/1624), operator
records of settled crypto-asset transactions must be retained and
re-verifiable for the statutory period.
* Under PSD2 (Directive 2015/2366) Article 89, the unauthorised-
payment refund obligation has timing tied to when the payment was
settled, not when it was broadcast. A PENDING_FINALITY state is
operationally distinct from a SETTLED state for refund-window
calculation purposes.
* Under EU Anti-Money Laundering Directives 5 and 6, a settled
payment that is subsequently REVERSED (for example by chain
reorganisation or court-ordered fraud reversal) requires an audit
trail recording the reversal event independently of the original
settlement event.
A receipt format that collapses these distinctions to a binary
"settled / not settled" or to a continuous "confirmation depth"
representation loses the load-bearing operational distinction.
This document specifies a settlement attestation format that
preserves the categorical outcome at the canonical-bytes level and
records the settlement chain explicitly, enabling multi-chain
operator audit trails under one canonicalisation discipline.
1.2. Scope
This document specifies:
* The canonical JSON shape of the settlement attestation
(Section 3).
* The reference to the canonicalisation rule applicable to the
receipt (Section 4 -- normative reference to draft-hopley-x402-
canonicalisation-jcs, not redefined inline).
* The audit chain composition under which settlement attestations
compose with compliance receipts and refund receipts (Section 5).
* The year-N auditability properties the format pins (Section 6).
* Composition patterns across the AlgoVoi receipt-format suite
(Section 7).
* Worked examples covering SETTLED, PENDING_FINALITY, and REVERSED
outcomes (Appendix A).
This document does NOT specify:
Hopley Expires 1 December 2026 [Page 4]
Internet-Draft x402-settlement-attestation May 2026
* The chain-specific finality model. The receipt identifies the
chain via settlement_chain; verifiers apply chain-specific
finality semantics (Algorand's deterministic instant finality,
Ethereum's probabilistic depth-based finality, Stellar's SCP,
etc.) at verification time.
* Cryptographic settlement proofs. Cryptographically-strong post-
quantum settlement proofs are an orthogonal mechanism specified
elsewhere. The two layers compose: a categorical settlement
attestation under this format MAY reference a cryptographic
settlement proof in its settled_payment_ref or via a separate
audit-chain row.
* Cross-chain bridge mechanics. The format supports cross-asset
substitution (the settlement_amount.asset_id MAY differ from the
original payment asset) but the bridge mechanism is out of scope.
1.3. Relationship to other Internet-Drafts
This document normatively references:
* draft-hopley-x402-canonicalisation-jcs -- the JCS canonicalisation
discipline pinned in Section 4.
This document is complementary to:
* draft-hopley-x402-compliance-receipt -- admission-time compliance
screening receipts. A settlement attestation's
settled_payment_ref MAY equal the content_hash of a compliance
receipt.
* draft-hopley-x402-refund-receipt -- post-settlement refund
receipts. A refund receipt's original_payment_ref MAY equal the
content_hash of a settlement attestation under this document.
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
*settlement attestation*: a JSON object of the shape specified in
Section 3, canonicalised under the discipline of draft-hopley-x402-
canonicalisation-jcs.
Hopley Expires 1 December 2026 [Page 5]
Internet-Draft x402-settlement-attestation May 2026
*content_hash*: SHA-256, lowercase hex, of the JCS-canonical bytes of
the attestation object.
*settled_payment_ref*: a string of the form sha256:<lowercase-hex-64>
identifying the payment record being settled by content hash. The
original record MAY be a compliance receipt, an operator-specific
payment authorisation record, or a cryptographic settlement proof.
*settlement_chain*: a string identifier for the chain on which
settlement occurred. See Section 3.5.
*settlement_amount*: a two-field object {amount_minor, asset_id}
representing the settled value.
*canon_version*: an in-band string identifying the canonicalisation
discipline. Fixed value jcs-rfc8785-v1 for this version.
3. Receipt Format Specification
A settlement attestation is a JSON object with the following eight
fields. All fields are REQUIRED. The attestation is canonicalised
under draft-hopley-x402-canonicalisation-jcs per Section 4. Field
names are sorted lexicographically by JCS during canonicalisation;
the object itself uses arbitrary authoring order.
3.1. settlement_result
A string-valued field. The value MUST be one of:
* SETTLED -- payment confirmed on-chain with sufficient finality for
the operator's risk model. Funds transferred and irreversible
under normal chain operation.
* PENDING_FINALITY -- payment broadcast and included in a block,
awaiting the operator's required confirmation depth. Operator has
visibility of inclusion but does not yet assert finality.
* REVERSED -- payment previously SETTLED is now considered reversed
(chain reorganisation, fraud reversal, double-spend resolution,
operator-initiated under regulatory directive).
The three-element enumeration is closed. Implementations MUST reject
any other value at validation time before canonicalisation. Score,
depth, or confirmation-count representations are not acceptable
substitutes for the categorical outcome.
Hopley Expires 1 December 2026 [Page 6]
Internet-Draft x402-settlement-attestation May 2026
The regulatory distinction is load-bearing. Under MiCA Article 80,
settlement-finality records must be retained and re-verifiable;
SETTLED is the operational state that triggers this obligation.
Under PSD2 Article 89, refund-window timing is tied to settled state.
Under AML Directives 5 and 6, reversed transactions require
documented evidence chains independent of the original settlement.
3.2. jurisdiction_flags
An ordered array of string-valued ISO-3166-1 alpha-2 country codes or
alpha-3 region codes identifying the applicable regulatory frameworks
for the settlement event.
Authoring convention: primary jurisdiction first (where the operating
entity is licensed), secondary jurisdictions in order of regulatory
precedence.
Array element ORDER is SIGNIFICANT and load-bearing per draft-hopley-
x402-canonicalisation-jcs Section 4.3.
3.3. settled_payment_ref
A string-valued field of the form sha256:<lowercase-hex-64>. The hex
digest is SHA-256 of the JCS-canonical bytes of the payment record
being settled.
When settling a payment that was admitted under a compliance receipt
(per draft-hopley-x402-compliance-receipt), the settled_payment_ref
MAY equal the content_hash of the compliance receipt itself. This is
the conventional choice and enables the audit-chain composition
described in Section 5.
When the original payment record is an operator-specific format
(payment authorisation, mandate, settlement proof, etc.), the
settled_payment_ref is the SHA-256 of that record's JCS-canonical
bytes.
Implementations MUST NOT strip the sha256: prefix during
canonicalisation or verification.
3.4. settlement_amount
A sub-object with exactly two fields:
* amount_minor -- a string of decimal digits representing the
settled value in the asset's minor unit. String typing avoids
float-precision loss and JavaScript-integer-overflow concerns for
large values.
Hopley Expires 1 December 2026 [Page 7]
Internet-Draft x402-settlement-attestation May 2026
* asset_id -- a string identifying the asset and its decimal
precision. Convention: <symbol>.<decimals> for chain-native
assets (e.g. USDC.6, ALGO.6, ETH.18);
<chain>:<asset_id>.<decimals> for ASA-style assets (e.g.
algo:31566704.6).
The sub-object's keys are sorted lexicographically by RFC 8785 during
canonicalisation: amount_minor then asset_id.
Cross-asset substitution is permitted. When settlement is in a
different asset than the original payment (e.g. paid USDC on Base,
settled USDC on Solana via a bridge), settlement_amount.asset_id
reflects the SETTLED asset, not the original. The equivalence-of-
value claim across the substitution is operator-layer and out of
scope.
3.5. settlement_chain
A string-valued field identifying the chain on which settlement
occurred. The string is in one of two forms:
1. Default mainnet of a chain family: <chain_family>. Examples:
* algo -- Algorand mainnet
* voi -- VOI mainnet
* solana -- Solana mainnet
* stellar -- Stellar Pubnet
* hedera -- Hedera mainnet
* base -- Base L2 mainnet (alias for ethereum:8453)
2. Non-default network of a chain family: <chain_family>:<network>.
Examples:
* algorand:testnet -- Algorand TestNet
* ethereum:1 -- Ethereum mainnet
* ethereum:8453 -- Base L2 (canonical by chainId)
* tempo:mainnet -- Tempo mainnet
* solana:devnet -- Solana devnet
The string is case-sensitive at the JCS layer. Implementations
SHOULD canonicalise to lowercase before emission. Verifiers MUST
treat Ethereum:8453 and ethereum:8453 as distinct canonical bytes per
RFC 8785.
Hopley Expires 1 December 2026 [Page 8]
Internet-Draft x402-settlement-attestation May 2026
The receipt does not decompose the chain identifier into a sub-
object. Operators requiring richer chain metadata (block height,
confirmation count, validator quorum at settlement time) MUST emit
those as separate operator-layer audit records, not as nested fields
in this receipt.
3.6. settlement_provider_did
A string-valued DID URI identifying the entity attesting settlement
(gateway, facilitator, oracle, or operator).
3.7. settlement_timestamp_ms
An integer-valued field carrying the epoch-millisecond timestamp of
the settlement event in UTC.
This field MUST be an integer. RFC 3339 string forms (e.g.
"2026-05-30T12:00:00Z") MUST be rejected at the validation layer
before canonicalisation. This is Substrate Rule 2, normatively
specified in draft-hopley-x402-canonicalisation-jcs Section 4.1.
3.8. canon_version
A string-valued in-band canonicalisation rule pin. For this version
of the receipt format the value MUST be jcs-rfc8785-v1.
4. Canonicalisation
The settlement attestation MUST be canonicalised under the discipline
pinned by draft-hopley-x402-canonicalisation-jcs and identified by
the URN:
urn:x402:canonicalisation:jcs-rfc8785-v1
The full normative specification of the discipline (JCS RFC 8785 plus
the schema-normalisation requirements including Substrate Rule 2) is
in that document. This document does not redefine the discipline
inline.
5. Audit Chain Composition
A settlement attestation MAY participate in an audit chain alongside
compliance receipts, refund receipts, and other receipt classes that
pin the same canonicalisation discipline.
Hopley Expires 1 December 2026 [Page 9]
Internet-Draft x402-settlement-attestation May 2026
5.1. Chain Row Shape
The audit chain row shape used by this document is identical to that
specified in draft-hopley-x402-compliance-receipt Section 5.1 and
draft-hopley-x402-refund-receipt Section 5.1:
{
"row_number": 1,
"content_hash": "<hex64>",
"prev_hash": "<hex64>",
"row_content_hash": "<hex64>"
}
Row 1's prev_hash MUST be 64 zero hex characters. Row N's prev_hash
MUST equal row N-1's row_content_hash.
5.2. Linkage Verification
Per draft-hopley-x402-compliance-receipt Section 5.2: a verifier
reading a chain segment recomputes each row's row_content_hash from
its first three fields and confirms forward linkage via prev_hash.
Any mismatch indicates tampering or chain integrity loss.
5.3. Composition with Compliance Receipts
When a settlement attestation references a compliance receipt via
settled_payment_ref, the audit-chain composition is:
chain row N chain row N+1
+------------+ +-------------+
| compliance |-->| settlement |
| receipt | | attestation |
| (ALLOW) | | (SETTLED) |
+------------+ +-------------+
Row N anchors the compliance receipt. Row N+1 anchors the settlement
attestation. The settlement attestation's settled_payment_ref equals
row N's content_hash. Chain linkage via prev_hash confirms ordering.
5.4. Composition with Refund Receipts
When a settled payment is subsequently refunded, the refund receipt's
original_payment_ref MAY equal the content_hash of the settlement
attestation. The chain extends:
Hopley Expires 1 December 2026 [Page 10]
Internet-Draft x402-settlement-attestation May 2026
chain row N+1 chain row N+2
+-------------+ +------------+
| settlement |->| refund |
| attestation | | receipt |
| (SETTLED) | | (FULL) |
+-------------+ +------------+
A verifier walking the full chain confirms admission -> settlement ->
refund under one canonicalisation pin.
6. Year-N Auditability Properties
The same six properties pinned by draft-hopley-x402-canonicalisation-
jcs Section 5 apply to the settlement attestation:
1. Self-describing canonicalisation pin via canon_version.
2. No external rule registry required.
3. Cross-implementation verifiability (8-implementation matrix per
the discipline I-D Section 7).
4. Tamper detection via per-row content_hash and chain prev_hash
linkage.
5. Regulatory distinction preserved via closed enumeration.
Plus one settlement-specific property:
6. *Chain-aware finality semantics applied at verification time.*
The settlement_chain string identifies which chain's finality
model applies. A verifier years after the event can apply the
correct chain-specific finality semantics to re-evaluate the
original SETTLED claim against retained chain state (block
height, confirmation depth, etc.).
7. Composition with Other x402 Substrate
7.1. Compliance Receipt Linkage
See Section 5.3. The conventional settled_payment_ref target for an
admission-then-settlement flow is the content_hash of the compliance
receipt that admitted the original payment.
7.2. Refund Receipt Linkage
See Section 5.4. A refund receipt's original_payment_ref MAY equal a
settlement attestation content_hash rather than the underlying
compliance receipt, producing a precise "the settled payment was
reversed" audit trail.
Hopley Expires 1 December 2026 [Page 11]
Internet-Draft x402-settlement-attestation May 2026
7.3. Cryptographic Settlement Proofs
Cryptographically-strong settlement proofs (post-quantum proofs of
payment conditions, validator signatures, STARK proofs of inclusion,
etc.) are orthogonal to the categorical settlement attestation
specified by this document. The two layers compose:
* A categorical settlement attestation records the operator's
categorical claim (SETTLED / PENDING_FINALITY / REVERSED) at the
canonical-bytes level.
* A cryptographic settlement proof provides byte-level evidence of
the underlying on-chain condition.
Both MAY be retained alongside one another, or chained via
settled_payment_ref references, depending on operator requirements.
8. IANA Considerations
8.1. URN Namespace Registration
This document references the URN urn:x402:canonicalisation:jcs-
rfc8785-v1 registered by draft-hopley-x402-canonicalisation-jcs
Section 10.1. No additional URN namespace registration is required
by this document.
8.2. Receipt Format Identifier
This document defines the receipt format identifier:
urn:x402:receipt:settlement-attestation-v1
This identifier MAY be used by composite-trust-query implementations
to refer to settlement attestations as a class. Registration with
IANA is requested under the x402 URN namespace.
9. Security Considerations
9.1. Attestation Tampering
A settlement attestation's content_hash is the SHA-256 of its JCS-
canonical bytes. Tampering with any field produces a different hash;
the tampered attestation fails verification against any audit-chain
row referencing the original content_hash.
Hopley Expires 1 December 2026 [Page 12]
Internet-Draft x402-settlement-attestation May 2026
9.2. Chain Reorganisation
A SETTLED attestation may later become incorrect if the underlying
chain reorganises and the settled transaction is no longer canonical.
The REVERSED outcome records this event. Operators SHOULD emit a
REVERSED attestation when a previously SETTLED state is invalidated;
the audit chain extends rather than overwrites.
A malicious operator could emit a SETTLED attestation for a payment
that never reaches chain-finality, then fail to emit the
corresponding REVERSED. Detection is verifier-side: a verifier
SHOULD periodically re-check chain state against retained SETTLED
attestations and flag discrepancies.
9.3. Chain Identifier Spoofing
The settlement_chain field is operator-asserted. A verifier MUST NOT
trust the chain identifier alone; verification against actual chain
state (via the verifier's own chain client) is required to confirm
settlement.
9.4. Cross-Asset Substitution
When settlement_amount.asset_id differs from the original payment
asset, the equivalence-of-value claim is operator-asserted. A
verifier cannot determine equivalence from the receipt alone;
external evidence (price oracle attestations at settlement time,
bridge proofs) is required and out of scope of this document.
9.5. Operator Continuity Loss
If the original attesting operator becomes unavailable, the audit
chain and its attestations MUST remain independently verifiable from
retained bytes plus the reference implementations cited in draft-
hopley-x402-canonicalisation-jcs Section 7.
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.
Hopley Expires 1 December 2026 [Page 13]
Internet-Draft x402-settlement-attestation May 2026
* [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785,
June 2020.
* draft-hopley-x402-canonicalisation-jcs Hopley, C., "JCS
Canonicalisation Discipline for Agentic-Payment Receipts", draft-
hopley-x402-canonicalisation-jcs-v1, May 2026.
A.2. Informative References
* draft-hopley-x402-compliance-receipt Hopley, C., "Categorical
Compliance Screening Receipt Format for Agentic-Payment Flows",
draft-hopley-x402-compliance-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.
* [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)
* 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 Payment Services Directive 2 (PSD2, Directive 2015/2366),
Article 89.
* EU Anti-Money Laundering Directive 5 (Directive (EU) 2018/843).
* EU Anti-Money Laundering Directive 6 (Directive (EU) 2018/1673).
* EU Digital Operational Resilience Act (DORA, Regulation (EU)
2022/2554), Article 14.
Appendix B. Appendix A. Examples (Informative)
B.1. A.1. SETTLED on Base under UK + EU joint jurisdiction
{
"canon_version": "jcs-rfc8785-v1",
"jurisdiction_flags": ["UK", "EU"],
"settled_payment_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
"settlement_amount": {"amount_minor": "100000", "asset_id": "USDC.6"},
"settlement_chain": "ethereum:8453",
"settlement_provider_did": "did:web:api.algovoi.co.uk",
"settlement_result": "SETTLED",
"settlement_timestamp_ms": 1716494400000
}
Hopley Expires 1 December 2026 [Page 14]
Internet-Draft x402-settlement-attestation May 2026
Records that 0.1 USDC was settled on Base mainnet (chainId 8453)
under joint UK + EU jurisdiction. The PSD2 Article 89 refund-window
clock begins at settlement_timestamp_ms. MiCA Article 80 record-
keeping obligations apply to retention of this attestation.
B.2. A.2. PENDING_FINALITY on Algorand
{
"canon_version": "jcs-rfc8785-v1",
"jurisdiction_flags": ["UK"],
"settled_payment_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
"settlement_amount": {"amount_minor": "100000", "asset_id": "USDC.6"},
"settlement_chain": "algo",
"settlement_provider_did": "did:web:api.algovoi.co.uk",
"settlement_result": "PENDING_FINALITY",
"settlement_timestamp_ms": 1716494400000
}
Records broadcast-and-inclusion on Algorand mainnet without yet
asserting operator-required confirmation depth.
B.3. A.3. REVERSED on Ethereum mainnet after chain reorg
{
"canon_version": "jcs-rfc8785-v1",
"jurisdiction_flags": ["UK", "EU"],
"settled_payment_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
"settlement_amount": {"amount_minor": "100000", "asset_id": "USDC.6"},
"settlement_chain": "ethereum:1",
"settlement_provider_did": "did:web:api.algovoi.co.uk",
"settlement_result": "REVERSED",
"settlement_timestamp_ms": 1716494400000
}
Records that a previously SETTLED payment on Ethereum mainnet is now
considered reversed. The audit chain extends with this row; the
prior SETTLED row remains as historical record.
Appendix C. Appendix B. Reference Implementations (Informative)
The following open-source implementations conform to this format:
* algovoi-settlement-attestation (Python) on PyPI:
target="https://pypi.org/project/algovoi-settlement-attestation/"
(https://pypi.org/project/algovoi-settlement-attestation/)
Provides build_settlement_attestation(). Depends on algovoi-
substrate for the JCS canonicalisation primitive. Apache 2.0
licensed.
Hopley Expires 1 December 2026 [Page 15]
Internet-Draft x402-settlement-attestation May 2026
* @algovoi/settlement-attestation (TypeScript) on npm:
target="https://www.npmjs.com/package/@algovoi/settlement-
attestation" (https://www.npmjs.com/package/@algovoi/settlement-
attestation) Byte-for-byte parity with the Python sibling.
Depends on @algovoi/substrate for the JCS canonicalisation
primitive. Apache 2.0 licensed.
Conformance vectors:
https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/tree/main/vectors/settlement_attestation_v1
8 byte-level reference vectors + 5 pair invariants + 3 chain
invariants pinning the closed-enumeration, jurisdiction-array-order,
canon_version pin, and audit-chain linkage properties.
Appendix D. Appendix C. Acknowledgments
This document, the receipt format it specifies, and the conformance
vectors derived from it are AlgoVoi work under sole AlgoVoi
authorship. Substrate authorship history is catalogued at
target="https://docs.algovoi.co.uk/substrate-authorship-provenance"
(https://docs.algovoi.co.uk/substrate-authorship-provenance).
The canonicalisation discipline pinned by Section 4 is normatively
specified in draft-hopley-x402-canonicalisation-jcs under the same
authorship.
This document closes the lifecycle gap between the admission-time
compliance receipt format (draft-hopley-x402-compliance-receipt) and
the post-settlement refund receipt format (draft-hopley-x402-refund-
receipt). The three formats share the same canonicalisation pin,
audit-chain row shape, and integer- millisecond timestamp encoding so
that a verifier walking the full payment lifecycle requires only one
implementation of the canonicalisation discipline.
The author acknowledges Anders Rundgren as the editor of RFC 8785,
the JSON Canonicalization Scheme on which the discipline builds.
Author's Address
Christopher Hopley
AlgoVoi
Email: chopmob@gmail.com
Hopley Expires 1 December 2026 [Page 16]