DEO conformance vectors 1.0 · Tzun specifications

The conformance vectors of the DEO verification specification, published as one archive. Specs §5 states what each file pins and Specs §6 what conformance to the vectors requires. Where a vector and the text of the specification differ, the text governs (Specs §7).

1. The archive

deo-vectors-1.0.tar.gz is a tar archive compressed with gzip. Every file in it sits under one directory, deo-vectors-1.0/. The panel at the top of this page gives the archive's size and SHA-256, and SHA256SUMS, published beside it, holds the same digest in the form sha256sum reads:

sha256sum -c SHA256SUMS            # or: shasum -a 256 -c SHA256SUMS
tar -xzf deo-vectors-1.0.tar.gz

Informative. The archive is built so that the same files always give the same bytes. Its entries are in byte order of their paths; every entry has the modification time 2000-01-01T00:00:00Z, owner and group 0, and mode 0644 for a file or 0755 for a directory; it is written in the ustar format; and gzip compresses it with -n -9, which leaves out the name and time of its input. Rebuilding it from the same files with GNU tar and GNU gzip gives the same SHA-256.

2. Files

File	What it pins	Sections
`merkle-rfc6962-vectors.json`	Leaf hashes, tree hashes and inclusion paths for trees of several sizes; the root of the empty tree; two leaf lists whose roots MUST differ	Tree §3.1 to §3.4, §9
`merkle-consistency-vectors.json`	Valid consistency proofs, their refused mutations, the edge rules, and the hash encoding rule	Tree §3.5, §4, §9
`v1.0-canonical-vectors.json`	Canonical bytes for payloads of v1.0, and inputs a serializer MUST refuse	Record §3
`v1.0-integrity-vectors.json`	The form of `canonicalDigest` and of the chain link	Record §4, §5
`signoff-expectation-vectors.json`	The grammar of `payload.signoffExpectation`, sign-off statement digests and challenges, the comparison a verifier makes between the expectation and the sign-off material a record carries, and the verdicts on whole records	Record §9, Verification §5
`checkpoint-vectors.json`	Checkpoint bodies and their digests, origins and origin binding, anchor-log leaves and P, and record artifacts with the rows each one yields	Anchor §4 to §6, §10.3, §10.6, §10.7
`evidence-log-origin-vectors.json`	The evidence-log origin for a range of chain ids	Anchor §4.3
`anchor-e2e-vectors.json`	Records anchored end to end on a local development chain: their artifacts, the epochs' anchor checkpoints, P and consistency proofs, and each publication with its heavy material	Anchor §6 to §10
`bundle-b1/`	`b1` bundles with the auditor's inputs, the expected report and the expected exit code, one directory per case	Bundle §13, Verification

The table is the one of Specs §5. Each file states, for every entry, the result the specification requires. These vectors predate the revision of Record 1.0 of 1 October 2026, which changed the hashed field set of v1.0 in place (Record §4.1). Their records were hashed under the earlier set 0.7, apart from one case hashed under before-0.7 on purpose and the cases tampered on purpose, and under the revised text none of their digests recomputes, so the records of signoff-expectation-vectors.json and anchor-e2e-vectors.json, the entries of v1.0-integrity-vectors.json whose hashedFields is the earlier set, and the b1 corpus are superseded; the corpus's expected reports also lack the rows of Verification §4.9 to §4.11 and the payload rows of Verification §4.7. The Tree vectors, the canonical serialization vectors and the checkpoint and origin vectors still hold. The vectors also predate the kind rule of Anchor §10.3 step 2b, which supersedes the checkpoint-vectors.json artifact case "a leaf of a store log of another kind, with no chain id: the chain is unchecked": the text gives anchor.origin checked-wrong, chain_id_mismatch, and the anchor false. The note of v1.0-integrity-vectors.json that names the session form cites it by its former section number; it is now Record §9.1. The archive is rebuilt from vectors written under the revised text, and until then the text governs (Specs §7). The members description, source, note, case, why, generator, format and notes are descriptive text and informative, as are the other members Specs §6 names.

3. The b1 corpus

3.1 Layout

The corpus holds cases for b1 record bundles, one directory each under bundle-b1/. Bundle §13 gives the files of a case, the format of inputs.json and how a verifier replays a case; Specs §6 states what conformance across the corpus requires. index.json names every case, its expected exit code, and the one thing it tests, and the corpus's README.md describes the cases as §3.3 does here.

3.2 The data

Every bundle holds a record of one store, anchored on a local development chain: anvil, CAIP-2 chain eip155:31337, whose finalized block trails its head by two. The store's anchor origin is test.bundle-b1.tzun/9029134276e6ed9c2815ff9b190a410a/anchors, a test origin (Anchor §4.3.4), and its publisher is anvil's development account 5, 0x9965507d1a55bcc2695c58ba16fb37d819b0a4dc. No network registry names eip155:31337, so anchorNetwork is null in every report.
Record timestamps are RFC 3161 tokens from a test authority whose root, "Tzun Corpus Test Root CA", exists only for this corpus. A case that trusts a root supplies that one in trustAnchorsPem. Apart from the record-token-* cases, every token passes each step of Anchor §10.5.
In every case the chain's block times are earlier than the tokens' genTime. The bound summary.existedBy names therefore follows the order of Verification §6.4: the record's anchor when anchor holds, the newer anchor when only anchor.newer holds, and the record's timestamp when neither does. Each of the three appears in some case.
Digests, origins, transaction ids, block numbers, block times and genTime values are those of the run the corpus comes from. Every outcome, reason and exit code is stated from the specification.

3.3 The cases

Grouped by what they exercise; the exit code follows each name.

Anchored records. anchored-with-newer (0): the record's own anchor, the newer anchor and both consistency proofs, every input supplied. anchored-latest-epoch (0), anchored-log-unchanged (0) and artifact-not-filled (0): the other shapes of Bundle §7.3 and §7.5.

Inputs withheld or relaxed. anchored-offline (4), anchored-offline-allow-unchecked (0), anchored-no-header-source (4), anchored-not-final (4), timestamp-untrusted (4).

The record's own token, one step of Anchor §10.5 each. record-token-not-der (1), record-token-digest-algorithms-malformed (1), record-token-unreadable-certificate (1), record-token-no-signing-certificate (1), record-token-no-timestamping-eku (1), record-token-issuer-name-reencoded (4).

Unanchored records. unanchored-awaiting-epoch (4), unanchored-allow-unchecked (0), unanchored-awaiting-finality (4), unanchored-pending-stripped (0), unanchored-pending-stripped-require-anchor (3).

The record altered. tampered-payload (1), envelope-version-unknown (4), rewrite-and-reseat (1), subject-mismatch (1).

The anchor altered. transplanted-leaf (1), transplanted-chain (1), tampered-log-path (1), tampered-anchor-path (1), forged-future-anchor-spec (4), artifact-stripped (4).

Publications. fabricated-header-offline (4), fabricated-header-with-source (1), manifest-chain-mismatch (1), sender-not-publisher (1).

Carried checkpoints and consistency. consistency-proof-tampered (1), consistency-proof-missing (4), newer-anchor-tampered (1), split-view (1), carried-checkpoints-contradict (4), checkpoints-of-two-logs-under-one-key (2).

Sign-off. signed-record (4), signature-stripped (4), session-record (4), session-signoff-stripped (1), session-signoff-transplanted (1), session-signoff-without-assertion (1), policy-session-signoff-without-assertion (1), junk-batch-signoff (1).

Material this version does not read. witness-extension (4), related-records-filled (4), policy-filled (4), unknown-member (4).

Bundles read as a whole. bundle-version-unknown (2), bundle-version-absent (2), bundle-chain-profile (2), bundle-unreadable (2).

3.4 Cases to read with care

unanchored-pending-stripped exits 0 with no anchor at all: exit code 4 counts artifacts that are present and undecided, and this one is missing (Verification §6.6). unanchored-pending-stripped-require-anchor is the same bundle under a regime that requires anchor, and exits 3. For a record whose envelope does not hold its artifact yet, as in artifact-not-filled, the row to require is anchor.newer.
session-signoff-stripped exits 1 with or without allowUnchecked: a session record's missing sign-off is a finding, not an unchecked artifact (Verification §5).

4. Corrections

Where an expected report and the specification disagree, the specification governs, and the corrected report names the section it follows (Specs §7). A corrected vector is published in a new version of this archive, at a new address; once this version is Frozen, the archive at this address keeps its bytes (Specs §8.4).

Download