Tanilo
Standards · Receipt Profile Registry

verification.v0.3 — issuer-side implementation.

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

Current status (6 November 2026). This page records dated demonstrations from June–August 2026. Today, Tanilo issues verification.v0.3+composed receipts from /evaluate and /v1/verify-facts, each with a single Tanilo signature from the key in the published key set. The service host’s /v1/compose and /v1/v_gate routes stopped issuing on 28 August 2026 (incident record), and the API gateway’s /v1/compose signing route was withdrawn on 24 September 2026; it has returned 410 since 28 September (trust). The three-signer examples below are historical; their keys stay published so they can still be verified.

Attribution. The registry itself is maintained by @wangbin9953 (independent ERC-8210 editor, agent.tech). Tanilo contributed the first profile entry via PR #4 ↗ (merged 2026-06-23 by the ERC author). As of June–August 2026, two issuers had demonstrated conformant receipts against the profile, Tanilo and AgentTrust, meeting the registry’s two-implementer threshold for elevating a pattern. That is a dated demonstration, not a statement about either issuer today.

Where verification.v0.3 is produced

The reference implementation of the profile lives at TKCollective/tanilo-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:

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:

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

Verifier implementations in three runtimes, with matching canonical hashes on the published fixtures:

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 Tanilo service required to verify a Tanilo receipt.

Normative spec

The profile as filed cites IETF draft-krausz-verification-state-01 for the on-wire semantics (act/halt verdict, canonicalization, signer binding) — that is what the entry's own text names, and it isn't rewritten here to track the -02 revision. The current revision is -03, filed 2026-10-01; feedback in the Datatracker or through the registry PR path is welcome.

Canonical URLs

Open questions from the ERC-8210 discussion

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. Update 2026-09-24: read this answer as dated, not as our current view. Tanilo no longer publishes a standing independence claim; what receipts do and don’t establish is on trust.