algovoi-retention-chain open source: Apache-2.0 receipt audit layer for AP2 payments (35 vectors, 8-lang cross-validated) + action_ref_exactly_once_v1 + adversarial_isolation_v1

[chopmob-cloud]

AlgoVoi has been contributing conformance vectors and cross-impl validation to AP2 over the past few months. This is a follow-on from that work.

We have just open-sourced the substrate layer under Apache-2.0:

pip install algovoi-retention-chain

What it does

Each x402/AP2 payment receipt carries a single retention_chain_ref field. Any auditor can recompute and verify the chain with no network access and no AlgoVoi infrastructure. The derivation is:

retention_chain_ref = "sha256:" + SHA-256(JCS({chain_seq, issuer_id, prev_receipt_hash, receipt_hash}))

JCS canonicalization is RFC 8785. The specification is IETF Internet-Draft draft-hopley-x402-retention-chain-01 (AlgoVoi, sole authorship, 16 June 2026).

Conformance

17 canonical vectors across two published sets (v0: 3 vectors, v1: 14 vectors). Cross-validated byte-for-byte across 8 implementations in 8 languages (Python, TypeScript, Go, Ruby, Rust, C#, Java, Kotlin). 61 byte-level assertions, all passing.

Conformance vectors: https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors

Why it is relevant to AP2

If you are implementing any payment receipt flow that needs to satisfy MiCA Art. 80, DORA Art. 14, or AMLR Art. 56 record-integrity obligations, the chain ref gives you a client-sovereign, infrastructure-free audit path. It is additive: no changes to the existing receipt schema, one new field.

More releases coming

For anyone already pinning algovoi-retention-chain==0.1.0, additional vector sets and a mandate-level audit layer are in progress. Expect further releases over the coming weeks.

Support offer

If you are building an AP2 receipt layer and want to verify your implementation against the canonical vectors, we are happy to help. AP2 has been a useful community to build alongside and this is a contribution back. Comment here or email chopmob@gmail.com.

AlgoVoi

[chopmob-cloud]

v0.2.0 — RFC 9421 support

pip install algovoi-retention-chain[rfc9421]==0.2.0

v0.2.0 adds an optional RFC 9421 (HTTP Message Signatures) layer. One call verifies both the HTTP signature on the receipt-carrying request and the retention chain ref:

from algovoi_retention_chain.rfc9421 import verify_signed_chain_link

result = verify_signed_chain_link(
    method="POST", authority="api.example.com", path="/receipts",
    headers=request_headers, body=request_body,
    public_key=issuer_ed25519_pubkey_hex,
    chain_ref=receipt["retention_chain_ref"],
    prev_receipt_hash=prev_hash, receipt_hash=receipt_hash,
    chain_seq=seq, issuer_id=issuer,
)
assert result.signature_valid  # RFC 9421 HTTP sig
assert result.chain_ref_valid  # chain integrity

The two checks are independent: signature_valid and chain_ref_valid are separate so you can distinguish a bad HTTP signature from a tampered chain ref. result.valid requires both.

Conformance: retention_chain_rfc9421_v1 — 3 vectors with real Ed25519 signatures over JCS-canonical receipt bodies, in the public conformance repo.

The core primitive, install, and pinning rules are unchanged. If you are pinning to implement the adoption programme checks, ==0.2.0 carries the same continuity guarantee as ==0.1.0.

[chopmob-cloud]

Substrate additions: action_ref_exactly_once_v1 + adversarial_isolation_v1

As we strengthen the L1 for the ecosystem, two new sets are now live in chopmob-cloud/algovoi-jcs-conformance-vectors. For existing adopters: the new vectors are available now. We welcome adopters, and more enhancements are coming — anyone building on the substrate benefits directly from each addition.

Both sets are released under Apache 2.0. The only condition is the licence's own: retain the NOTICE file on redistribution (Section 4(d)).

action_ref_exactly_once_v1 — 6 vectors, 5 pair invariants

Pins the full payment lifecycle: PENDING → COMMITTED → REVERSED.

Two invariants that matter for production:

SKIP-on-retry. A re-presented COMMITTED transition with identical action_ref, state, and timestamps reproduces the prior transition_hash byte-for-byte. A retry cannot produce a second effect, expressed as a hash assertion, not a prose rule:

action-ref-eo-v1-003 (COMMITTED, first):  f49faa7c4f82bd84...
action-ref-eo-v1-005 (COMMITTED, retry):  f49faa7c4f82bd84...  ← identical

Replay binding. Identical state + timestamps under a different action_ref produce a different transition_hash. A replayed transition cannot collide with another identity's record:

action-ref-eo-v1-003 (action_ref A):  f49faa7c4f82bd84...
action-ref-eo-v1-006 (action_ref B):  97124ca25721d0aa...  ← different

Cross-validated across 8 independent RFC 8785 implementations, 48/48 byte-for-byte. Anchored to draft-hopley-x402-retention-chain-02 §7.

adversarial_isolation_v1 — 12 vectors (1 control + 11 rejection)

Defines the exact inputs a conformant implementation must reject. Each vector mutates exactly one field so you can confirm the named check fires in isolation.

The most common cross-implementation mistake: timestamp_ms must be an epoch-millisecond integer, not a string. Vector adv-v1-001-ts-rfc3339 explicitly rejects "2026-06-09T00:00:00Z". If your implementation accepts that, it will diverge at the verification boundary.

Other rejection cases: negative timestamp, boolean as timestamp, non-hex action_ref, short action_ref, empty state, empty scope, chain prev_hash break, stale content_hash (payload mutated but hash not updated), wrong chain_position ordinal.

Claim 1 (input bytes) is 8-lang, 96/96 byte-identical. Claim 2 (rejection) is reference-impl proof-of-rejection only, not an 8-lang byte claim.

Anchored to draft-hopley-x402-retention-chain-02 §7.5 + §8.8.

Repo: chopmob-cloud/algovoi-jcs-conformance-vectors