Conformance vectors

Fixed inputs and expected verdicts, generated by the reference implementation's test suite and committed with it. A verifier written in any language proves it agrees with the reference by producing exactly these verdicts. The browser verifier on this site is the first such second implementation; its test runs every vector below.

file	contents
receipts.json	public keys by name, and fourteen receipt bundles with the keys to verify each against, an optional log copy, and the expected verdict: which checks must fail, if any. Gateway and SDK receipts, tampered payloads, re-signed edits, wrong keys, proofs for the wrong index, a log copy from another log, a remote log with and without its key.
audit.json	pairs of signed tree heads with a consistency proof and the expected audit verdict, including the wrong order, the wrong key, and a damaged proof.
merkle.json	seven leaves, their leaf hashes, the root at every size, an inclusion proof for every leaf, consistency proofs for several size pairs, and one rewritten-leaf case that must fail.
canonical.json	values with their canonical JSON and digests, a public key with its keyid, and a DSSE envelope with its pre-authentication encoding.

How to use them

For each case in receipts.json, load the named keys from keys, verify bundle, and when log is not null treat its strings as the lines of a log copy. Compare your failing check names with expected.failing; the names are listed on the specification. A verdict that differs is a bug in one of the two implementations, and the vector says which check disagrees.

The vectors are regenerated only when the format changes, by bun run vectors in the receipts package, and the change is committed and versioned with the specification. They are also shipped inside the npm package under vectors/.