Trust our storage.
Don't trust us — run this.

A witness is a small program that keeps one piece of state — the last checkpoint it accepted — and one secret: a signing key you generate. Each time we publish a new checkpoint, it verifies our signature, requests an RFC 6962 consistency proof between the old tree size and the new one, and recomputes the hashes itself. Only if that proof verifies does it co-sign. Because the key lives with you, a co-signature is a statement you made, not one we can manufacture. And because a refusal is recorded with both signed checkpoints, our own signature becomes the evidence against us.

Yes — that's the design goal. An inclusion proof is a leaf hash, an index, a tree size, and an audit path of sibling hashes. Given a checkpoint you already hold, verification is pure local computation: hash the record, walk the path, compare roots. The rootwitness verify command does this with the network disabled, on every plan including free — auditors can run it on an air-gapped machine, and it needs no account with us at all.

Your client canonicalizes and hashes the record locally and sends only the digest and non-sensitive metadata. We append the digest. You keep the plaintext in your own systems. Inclusion proofs, checkpoints, consistency proofs, and witness co-signing all work identically, because the log has never needed to read your data — only to hash it.

The witness refuses to co-sign, exits non-zero, and writes an evidence bundle containing both conflicting signed checkpoints, the proof it requested, and the response it received. Wire that exit code into your alerting. Nothing about the failure depends on us cooperating — the artifacts are already on your disk.

OpenTimestamps commits a checkpoint's root hash into a Bitcoin transaction, producing a timestamp attestation nobody — including us — can backdate. It answers a different question than the witness does: not "is the history consistent" but "did this root hash exist by this date," provable to a third party who has never heard of us. Combined with write-once checkpoint archival, it's the package auditors tend to ask for.

Two caveats we would rather you heard from us. A freshly submitted attestation is a calendar server's promise, not yet Bitcoin evidence — it becomes evidence once a block confirms, and our tooling reports which of the two you are holding. And anchoring is enabled per account rather than by paying, because the cadence and the retention rule are yours to choose. Ask and we will tell you exactly what is running on your account.

Because stronger language would be false. Nothing in software prevents a sufficiently privileged party from altering bytes. What a Merkle transparency log with independent witnesses gives you is that alterations to recorded history become detectable by parties who don't trust the operator, using math they can run themselves. That's a precise claim, and precision is why regulated buyers take it seriously.

The client library batches and returns as soon as the entry is durably queued, with a promise of a receipt at the next tree-head integration; you can also request synchronous receipts. Checkpoints are published on a fixed cadence, so witness verification cost is constant regardless of write volume.

Yes — github.com/725ttzn82p-beep/rootwitness, Apache 2.0. There is no binary to trust: it's a small pure-Python package you install from source and run yourself, four modules totalling a few hundred lines, so a security reviewer can read all of it in an afternoon. A verifier you can't audit would recreate the trust problem one layer down. We don't yet ship a reproducible build or signed release artifacts, because there's nothing compiled to reproduce — if you'd rather pin an exact commit, the repository is the artifact.