Test vectors

The files, and how they bind to each other

The manifest names the specification file, repeats its digest, names the fixture file, repeats the fixture's digest, and publishes a vector root that binds the two. The fixture in turn repeats the specification digest inside itself. Four independent places must agree before you can trust any single value, which is exactly the property you want from a corpus that other implementations are graded against.

vector_root = SHA256(
  "TANDEM/VECTOR-ROOT\0" ||  // 19 bytes
  "golden.json" ||           // the fixture file name, as ASCII
  00 ||                      // one separator byte
  fixture_sha256_32
)
= b7f22caf5c9b9f3562f4d842a60a4bb0daa3f2805a5b8ff73e4d716721882c11

The independent Rust verifier deliberately does not copy the vector root into its input lock. It pins the fixture file's digest and then derives the root itself, so an incorrect published root would be caught rather than trusted.

Identity

The corpus fixes one regtest binding. Every namespace field in every marker below is this namespace, which is the first cross-check available to a new implementation.

Both derivations are worked through in guide example 1 and recomputed live by the pair check tool.

The carrier pair

0279be667ef9dcbbac55a0
6295ce870b07029bfcdb2d
ce28d959f2815b16f81798

02c6047f9441ed7d6d3045
406e95c07cd85c778e4b8c
ef3ca7abac09b95c709ee5

Marker encodings

One valid marker per operation, published as both payload and full script. These are the fastest way to find an encoding bug: if your serializer produces different bytes for the same field values, the difference is visible immediately.

6a28544e444d0103010138025b6fb909d2f22226ee9ea7e3a0e895c589792a93
393c136ad502c608d221

6a4c50544e444d010304ff38025b6fb909d2f22226ee9ea7e3a0e895c589792a
93393c136ad502c608d221030000000000000042424527b3f6228a8ff8223239
35c83822439be948d634100c138faeff2402a1

83 bytes is the maximum Tandem marker script, corresponding to the 80-byte maximum payload. Note the encoding boundary between them: CREATE and ROTATE, at 40 and 44 bytes, use a direct push, while MARK and CLOSE, at 78 and 80 bytes, must use OP_PUSHDATA1 because a direct push tops out at 75. Using the wrong one is BAD_MARKER_ENCODING_OR_LENGTH. The pair check tool will show you that failure if you edit a push byte.

Two commitments

31 validation cases

The corpus fixes 31 named validation cases: six valid operations and 25 rejections. Every one of the 26 stable reasons in the registry is exercised. For each case the corpus records the emitted event type, validity class, and reason, which is what an implementation must reproduce.

The three most instructive rows

reject-namespace emits event type CREATE, not INVALID, even though it is class 0. That is rule INV-5's population rule at work: the marker exposed marker format 0x01 and a defined opcode, so the class 0 event carries the attempted operation type. Compare it with reject-opcode, where the opcode was not defined, so the type falls back to INVALID.

reject-commitment is class 2 with a terminal event, not class 0. A zero chapter commitment is a late failure, and by the time it is reached the transaction has already consumed a carrier. The object dies. Compare it with reject-tx-version, an early failure in the same corpus that is class 0 because the fixture has no carrier spend.

reject-multiple-carriers is the only case that emits two events from one transaction, each terminal, ordered by binary object key with sub_index 0 and 1. If your implementation emits one event here, or emits two in a different order, your event root will differ.

Roots

The corpus publishes complete preimages, not just results. That means you can find the exact byte where your implementation diverges, rather than only learning that it does.

Published example block

The roots section fixes one block-shaped example: three event leaves and two object snapshot leaves, at height 1200 with block hash b0b0…b0b0.

The third leaf shows the no-marker rule in practice: its event_index is 0xffffffff rather than a vout, because there was no marker to take a vout from. The second leaf shows the namespace population rule: its namespace field is zero32, because a payload that fails encoding is never structurally decoded far enough to extract one.

The event tree has three leaves, so it exercises the odd-leaf rule: at the first level the third leaf is duplicated and hashed with itself. The corpus publishes every intermediate Merkle level, so if your root differs you can see which level first diverges. The object tree has two leaves and needs no duplication.

The chained root closes the loop. Reconstructing it from the pre-INIT state root, the block hash, height 1200, the two component roots, and the post-block counters founding_created 1, all_objects 2, and active_objects 1 reproduces the published value exactly. That single 32-byte number is what two independent pipelines actually compare.

Reproduce them yourself

You do not have to take any of this on faith, and you should not. There are three independent ways to check the corpus, in increasing order of effort.

1. In your browser. Open the pair check tool. It loads this repository's published corpus, rehashes every preimage, rebuilds both Merkle trees, and reports each result individually.
2. With the repository verifier. Run node scripts/verify-public.mjs from the repository root. It checks the specification byte contract, every published artifact digest, and the manifest-to-fixture binding.
3. With the independent Rust verifier. See the verifier page. It recomputes the vector root rather than trusting it, and shares no code with the implementation that produced the corpus.