Two implementations,
no shared code.

Why two implementations

A metaprotocol is not enforced by Bitcoin consensus. Bitcoin will happily confirm a transaction that Tandem considers invalid. Everything above the script layer is decided by parsers, which means a single parser is a single point of failure with no external check on it.

The usual mitigation is to publish a specification and hope. Tandem goes further: the specification's own invariant 12 requires that independent implementations produce identical events, reason codes, state, counters, and all three roots at every height, given the same binding and the same blocks. That is a testable claim, and the second implementation exists to test it.

Different language, different runtime, different database, different developer assumptions. A bug that survives both is far more likely to be a specification problem than an implementation slip, which is exactly the class of problem you want surfaced before a network is live.

The shared surface, pinned by digest

The two implementations do share something, and being precise about what is the whole point. The Rust repository carries a lock file listing every shared artifact and its SHA256. Nothing else crosses the boundary.

Every one of those six digests matches the values this repository's own verifier pins in scripts/verify-public.mjs. Two independently maintained lists of hashes agreeing is a small thing, but it is the kind of small thing that stops a silent artifact swap.

Note what is not pinned. The vector root from the manifest is deliberately absent from the lock. The Rust verifier recomputes it from the fixture digest instead of trusting the published value, so an incorrect root would be caught rather than copied. The lock also refuses any path that is absolute or contains a parent-directory component, so a tampered lock cannot be used to read files outside the protocol directory it is pointed at.

What the Rust implementation verifies

Run it yourself

This is the part that matters. You do not need our infrastructure, our database, or our permission. You need a Rust toolchain and a checkout of two public repositories.

The verifier pins Rust 1.97.1 with a toolchain file, uses edition 2024, forbids unsafe code, and denies both the all and pedantic clippy groups. Its three crates are at version 0.1.0 and are not published to crates.io, so build from source.

cargo run -p tandem-cli -- verify-inputs \
  --lock protocol-inputs.lock.json \
  --protocol-root ../tandem

This reads every artifact named in the lock from your checkout of this repository and compares its digest. If someone has altered the specification, a schema, or the corpus, this is where it shows up.

cargo run -p tandem-cli -- verify-vectors \
  --manifest ../tandem/vectors/generated/manifest.json \
  --spec ../tandem/tandem.md

This one does the real work. It checks the manifest's schema identifier, confirms it names tandem.md and golden.json, recomputes the specification digest and the fixture digest, derives the vector root and requires it to equal the published one, confirms the fixture's own schema identifier, and confirms the specification digest recorded inside the fixture matches the one it just computed.

cargo run -p tandem-cli -- replay --input replay.json

A replay file supplies a binding, a list of block views, and optionally an array of expected roots per height. The CLI applies each block through the Rust reducer and fails with a root mismatch at the first height that diverges, which makes it a usable differential driver against any other implementation that can emit the same block views.

The verifier's own recorded verification run reports the same three roots this repository publishes: event root 475b25d2…fae046ce, object-state root 67ec64ab…7e110d79, and chained root c54cd3c6…6322e260. Those are the values on the vectors page, arrived at by different code.

cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features
cargo build --workspace --release --locked

Fuzzing and property tests

The verifier carries two cargo-fuzz targets, kept in their own workspace so they never enter a release build.

• Marker target. Feeds arbitrary bytes to the candidate detector and, on a hit, to the parser. The property is that arbitrary script bytes, including malformed push lengths, truncation, trailing data, and non-minimal encodings, always produce a reason rather than a panic.
• Replay target. Deserializes arbitrary block views against a fixed regtest binding and drives the reducer over the first 32 blocks. The property is that adversarial but type-valid input produces errors, never aborts.

Alongside them are property tests asserting that marker detection and parsing never panic, that any successfully parsed marker has a payload length in the range 7 to 80 and exactly the declared length for a defined opcode, that distinct CREATE transaction identifiers yield distinct object keys, and that the exact payload lengths match the specification.

What agreement actually proves

Independent agreement is a strong property and a narrow one. Being precise about its edges is what makes it worth anything.

The design is a comparison of signed outputs, not a differential test rig. Neither pipeline reads the other's output. Each processes the same height independently and signs a tuple. Agreement means the two signed tuples match on the nine semantic fields. When they do, you know:

• Two codebases, written in different languages, independently derived the same event set for that height.
• They agree on every object's status, sequence, key pair, carrier, and chapter count, because those all feed the object-state root.
• They agree on the whole history up to that height, because the chained root incorporates every previous block's root.
• A parser bug that changes any classification, any reason code, or any ordering would have to exist identically in both, which is unlikely for genuinely independent work.

That is a meaningful reduction in the risk that one parser silently presents incorrect state. It is the property the whole two-pipeline arrangement exists to produce, and it is worth building for.

How to respond to a disagreement

Fail closed. Do not present state for the disputed height and do not allow a state-changing construction against it. Then compare in a fixed order: event root, object-state root, counters, chained root. The first difference localizes the problem. All three components matching while the chained root differs points at the chaining input rather than at this block. Do not designate either pipeline as correct on the basis of ownership or release order.

What it does not prove

The honest summary: an independent second implementation in a different language is a genuinely strong trust property, and this one is real, runnable, and pinned to the same frozen bytes. What has not yet happened is the two pipelines agreeing continuously over a live chain for a sustained period. Until that is published, the property is demonstrated on a fixed corpus rather than proven in operation.