Standards · Receipt Profile Registry

verification.v0.3 — issuer-side implementation.

Issuer-side implementation details for verification.v0.3, the first entry in the ERC-8210 Receipt Profile Registry introduced by Jacky Wang in the ERC-8210 v2 Progress Update on 2026-07-05.

Attribution. The registry itself is maintained by @wangbin9953 (independent ERC-8210 editor, agent.tech). AgentOracle contributed the first profile entry via PR #4 (merged 2026-06-23). Two independent issuers produce conformant receipts against the profile: AgentOracle and AgentTrust — meeting the registry’s two-implementer threshold for elevating a pattern.

Where verification.v0.3 is produced

The reference implementation of the profile lives at TKCollective/agentoracle-receipt-spec, under examples/v0.3-composed/. It carries the full deterministic build (build_fixtures.py), three published JWKS (AgentOracle + AgentTrust + Presidio), and both accept and reject vectors as detached JWS files. Byte-identical rebuilds from a cold clone are part of the intended workflow — the spec assumes recompute discipline, not trust.

Multi-issuer composition

A single envelope carries up to three signer slots today:

v_gate — AgentOracle’s independent verifier
v_gate_skill — AgentTrust’s independent verifier (AgentTrust runs its own /v1/compose endpoint against the same canonical bytes; adapter merged into babyblueviper1/preaction-governance-conformance PR #2 on 2026-07-04)
screen_ref — Presidio’s screen leg (three-signer JWS on live bytes demonstrated in x402-foundation/x402 #2332, 2026-06-28)

Composition rule is AND_PRESENT — every present slot must recompute, or the composed decision halts. Conformance for that halt is comp-006 in the composed fixture set.

Conformance vectors, independent registry

Both issuers’ conformance suites are landed in giskard09/argentum-core:

AgentTrust conformance: PR #28, merged 2026-07-02.
Presidio decision_ref vectors: PR #29, merged 2026-06-30. See presidio-x402-decision-ref-v1.fixture.json for the three vectors (accept + signer-equals-runtime reject + verdict-not-recomputable reject).

Both were independently recompute-graded by @babyblueviper1 before merge — the two-implementers threshold is grounded in that cross-implementation verification, not in issuer self-attestation.

Verification tooling

Byte-identical verifiers across three languages:

Node: verify_node.mjs in the reference repo (jose)
Python: pip install agentoracle-receipt-verify — pypi.org/project/agentoracle-receipt-verify/, live since 2026-07-02
Browser: WebCrypto-only bundle, same JCS + Ed25519 semantics

All three consume the same JWKS files and produce the same canonical hash byte-for-byte, so a receipt can be verified anywhere the client can compute SHA-256 + Ed25519. No AgentOracle service required to verify an AgentOracle receipt.

Normative spec

The profile references IETF draft-krausz-verification-state-01 for the on-wire semantics (act/halt verdict, canonicalization, signer binding). The draft is an individual submission at I-D Exists; feedback in the Datatracker or through the registry PR path is welcome.

Canonical URLs (as delivered to Jacky)

(a) /v1/compose reference implementation

Spec + fixtures + build script + three JWKS

(b) argentum-core PR #28

AgentTrust conformance, merged 2026-07-02

Presidio decision_ref vectors, merged 2026-06-30

(d) agentoracle-receipt-verify on PyPI

Python verifier, byte-identical to Node and browser siblings

On the two open questions from ERC-8210 Post 46

Q4 — multi-issuer envelope citation strategy

Direction B (protocol-neutral prose in Rationale, registry as the naming mechanism) reads cleanly from the issuer side. The registry is content-addressed on keccak256(profile_identifier), so the identifier itself is the citation — subsequent profile entries won’t require ERC revisions to be reachable. Registry-first stays honest as the profile set grows.

Q2 — behavioral similarity as a fifth independence category

No strong opinion. If it lands as a non-breaking extension in IIndependenceSignal, verification.v0.3 wouldn’t need any changes to accommodate it — the profile is independence-model agnostic.