Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt

Use this file to discover all available pages before exploring further.

The settlement attestation closes the lifecycle gap between admission-time compliance receipts and post-settlement refund receipts. It 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. It is AlgoVoi-authored, specified in IETF Internet-Draft draft-hopley-x402-settlement-attestation (POSTED on IETF datatracker 2026-05-25, Independent Submission, Informational), and published as a standalone reference implementation: Both packages depend on algovoi-substrate / @algovoi/substrate for the JCS canonicalisation primitive. Apache 2.0.

Lifecycle position

admission         settlement        refund
compliance   -->  settlement   -->  refund
receipt           attestation       receipt
All three formats anchor to the same canonicalisation discipline (urn:x402:canonicalisation:jcs-rfc8785-v1). A verifier walking the audit chain confirms admission → settlement → refund under one byte-deterministic pin.

Why this format

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:
  • Under MiCA Article 80 (Regulation (EU) 2023/1114) and AMLR 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 Article 89 (Directive 2015/2366), the unauthorised-payment refund obligation is tied to when the payment was settled, not broadcast. A PENDING_FINALITY state is operationally distinct from SETTLED for refund-window calculation.
  • Under AML Directives 5 and 6, a settled payment that is subsequently REVERSED (by chain reorganisation or court-ordered fraud reversal) requires an audit trail independent of the original settlement event.
The receipt format preserves these distinctions at the canonical-bytes level via a closed three-element enumeration.

Receipt shape

A settlement attestation is an eight-field JSON object canonicalised under RFC 8785 (JCS). Field names are sorted lexicographically by JCS during canonicalisation.
{
  "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
}
FieldTypeDescription
canon_versionstringIn-band canonicalisation pin. Fixed jcs-rfc8785-v1.
jurisdiction_flagsordered arrayISO-3166-1 codes. Order significant under RFC 8785.
settled_payment_refstringsha256:{hex} reference to original payment record.
settlement_amountobject{amount_minor: string, asset_id: string}.
settlement_chainstring{chain_family} or {chain_family}:{network} (e.g. algo, solana, ethereum:8453).
settlement_provider_didstringDID URI of attesting party.
settlement_resultstring (closed enum)SETTLED / PENDING_FINALITY / REVERSED.
settlement_timestamp_msintegerEpoch milliseconds. Substrate Rule 2.

The closed enumeration: settlement_result

ValueSemanticRegulatory significance
SETTLEDPayment confirmed on-chain with sufficient finality for the operator’s risk model.Triggers MiCA Art. 80 / AMLR Art. 56 record-keeping. PSD2 Art. 89 refund-window clock starts.
PENDING_FINALITYPayment broadcast and included, awaiting the operator’s required confirmation depth.Operator has visibility but does not assert finality. PSD2 refund-window timing differs from SETTLED.
REVERSEDPreviously SETTLED payment now considered reversed (chain reorg, fraud reversal, operator-initiated under regulatory directive).Triggers reversal-evidence obligations under POCA s.330 and AML5/6.
Each value produces a byte-distinct content_hash. Score, depth, or confirmation-count representations are not acceptable substitutes.

Multi-chain settlement_chain identifiers

AlgoVoi’s production xChain runs on 8 chain families. Conventional identifiers:
ChainIdentifier
Algorand mainnetalgo
VOI mainnetvoi
Solana mainnetsolana
Stellar Pubnetstellar
Hedera mainnethedera
Base L2base or ethereum:8453
Tempo mainnettempo:mainnet
Ethereum mainnetethereum:1
The string is opaque under JCS — case-sensitive, no decomposition. Operators requiring richer chain metadata emit it in separate operator-layer audit records, not as nested fields.

Composition

A settlement attestation settled_payment_ref MAY reference a compliance receipt content_hash. A refund receipt original_payment_ref MAY reference a settlement attestation content_hash. The full lifecycle chain:
compliance receipt (ALLOW)
    |
    v   (settled_payment_ref)
settlement attestation (SETTLED)
    |
    v   (original_payment_ref)
refund receipt (FULL | PARTIAL | REJECTED)
A verifier walking this chain confirms admission → settlement → refund under one canonicalisation pin.

Conformance vectors

8 byte-level reference vectors + 5 pair invariants + 3 chain invariants at vectors/settlement_attestation_v1/.

Quick start

TypeScript

import { buildSettlementAttestation } from "@algovoi/settlement-attestation";
import { sha256Jcs } from "@algovoi/substrate";

const a = buildSettlementAttestation({
  settled_payment_ref:
    "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  settlement_result: "SETTLED",
  settlement_timestamp_ms: 1716494400000,
  settlement_provider_did: "did:web:api.algovoi.co.uk",
  settlement_amount: { amount_minor: "100000", asset_id: "USDC.6" },
  settlement_chain: "ethereum:8453",
  jurisdiction_flags: ["UK", "EU"],
});
console.log(sha256Jcs(a));
// 0ead75bfe7fc74cc0421124903e56cb5c5006d02c393231a1d5f260fa87e96d3

What this is NOT

  • Not a cryptographic settlement proof. Cryptographic proofs of payment conditions are orthogonal; this format records the operator’s categorical claim at the canonical-bytes level. The two layers compose.
  • Not a chain-specific finality declaration. Chain-specific finality semantics (block depth, validator quorum) are out of scope; verifiers apply them at verification time.
  • Not a cross-chain bridge proof. Cross-asset substitution is permitted in the format; the bridge mechanism is out of scope.

Companion IETF Internet-Draft

draft-hopley-x402-settlement-attestation (Independent Submission, Informational). AlgoVoi-authored, sole authorship. Normatively references draft-hopley-x402-canonicalisation-jcs-v1.

See also