Most “audit logs” ask you to trust the operator — the same party who would do the rewriting. TillNotary is built so you don’t have to: every claim is backed by a proof you check yourself, client-side, against keys you pin. We won’t tell you the record can’t be tampered with; no honest engineer can. What we can prove is stronger than the usual promise: a rewrite breaks every proof issued before it, so it is detected the moment anyone holding one checks — and an undetected rewrite would need the log operator, every witness you require, and every holder of an earlier head to fail at once. Attach a witness you run and keep a mirror, and two of those three are yours.
Read the diagram as an equation: undetected rewriting requires operator ∧ witnesses ∧ holders, all at once. One honest party anywhere — one witness that checks its consistency proof, one mirror or receipt holding yesterday’s head — and the rewrite is caught, with signed evidence of who diverged. That precision is why you can put this record in front of an auditor, a court, or a customer.
You submit 32 opaque bytes — a hash you computed locally. What comes back is not a status page’s word for it; it’s four artifacts your own code can verify.
For every entry, a Merkle path from your hash to a signed head: cryptographic proof your record is in the log, checkable in microseconds by anyone holding the head. Not a receipt — a proof.
› Read the docsEvery new head proves it extends the previous one — nothing removed, nothing reordered, history append-only. This is the proof that makes a silent rewrite mathematically loud.
› Read the docsWitnesses verify consistency, then cosign the head with their own keys: ours by default, and yours or a third party’s when you attach them. With a witness you run in the quorum, we can’t backdate an entry alone.
› Read the docsOne portable file: your hash, the proofs, the head, the cosignatures. It verifies offline, forever, against keys you pinned — even if TillNotary is unreachable or gone.
› Read the docsSuppose the log were rewritten — an entry dropped, history forked, a head replaced. The next consistency proof cannot be constructed honestly, so the witness’s check fails. It refuses to cosign and publishes a signed refusal: which head, which check, when. From that moment, every verifier on earth can see the record lost its quorum.
This is what “tamper-evident” means mechanically. The system’s failure mode isn’t a quiet gap in a database — it’s a loud, signed statement from the witness that something diverged.
Witness protocol →verify firstA witness never cosigns on our say-so. It recomputes the consistency proof against the last head it signed. If the math holds, it signs; if not, it doesn’t. There is no override.
refuse in writingA failed check doesn’t just withhold a signature — the witness publishes a signed refusal naming the head and the reason. The refusal is itself permanent, verifiable evidence.
quorum or nothingA head without its witness quorum is not a valid timestamp, and every verifier knows it. Losing cosignatures is loud by construction — silence is impossible to fake.
your key in the quorumA new log is cosigned by our witness. Attach one you run, or one a party you trust runs, and require it: then no head completes without a key we don’t hold.
A timestamp you rely on in 2036 is only as strong as its signatures are then. So TillNotary signs everything twice — classical and post-quantum — and treats the pair as one signature: both must verify. Not a fallback, an AND.
SHA-256 · Ed25519 + ML-DSA-65Every head signature and every witness cosignature is hybrid: classical Ed25519 and ML-DSA (FIPS 204), and verification requires BOTH to pass. A forgery needs both schemes broken at once — and if either one falls tomorrow, your existing evidence still stands on the other.
CNSA 2.0 algorithms · SHA-384 · ML-DSA-87For records held to CNSA 2.0 algorithm levels: SHA-384 throughout the tree and ML-DSA-87 signatures at the highest standardized security category. Same log semantics, same proofs — a stricter suite, selectable per log.
every bundle names its suiteEvidence often has to outlive the algorithms that signed it. Each head and each bundle declares its exact suite. Adopting a new suite means starting a new log; existing logs and every bundle they issued keep verifying, and verifiers always know precisely what they are checking.
Verification runs on your machine, against keys you pinned, with no network call. The hash is computed locally, so your bytes never leave; the bundle is a file, so it verifies in an air-gapped room ten years from now.
Your application keeps its own hash-chained audit log — but a chain can be quietly truncated by whoever holds it. Anchor its head into TillNotary on a schedule and truncation becomes detectable by anyone, against a record the log’s owner doesn’t control.
Notarize the digest of every artifact at build time. Anyone installing it can verify the binary in their hands is byte-for-byte the one that existed at the recorded moment — before it passed through registries, CDNs, and mirrors you don’t control.
A contract, a design, a disclosure, a lab notebook page: prove it existed, exactly as it is, at a point in time — without revealing a word of it. The log holds a hash; the document never leaves your custody.
Notarize each backup manifest’s hash when the backup is taken. If an incident ever raises the question “was this restored from the real backup, or a doctored one?”, the answer is a proof — not a debate.
The strength of a transparency log comes from how little it does. Three boundaries worth being explicit about:
No tokens, no mining, no consensus protocol. A transparency log needs none of it: an append-only Merkle tree plus witnesses you choose delivers verifiability at web latency, at web cost. The lineage here is Certificate Transparency, not cryptocurrency.
Leaves are opaque hashes — never queryable business data. Your records stay in your systems, under your access controls; the log holds only commitments to them. If you can read customer data out of it, someone used it wrong.
Never submit personal data — submit its hash. And remember hashes of guessable values (a phone number, a national ID) can be brute-forced from a public log: for low-entropy data, notarize a salted commitment instead. The docs show the pattern.
Privacy, by construction. Because leaves are opaque hashes by default, the log can be public and gossiped — which is exactly what makes it strong — while revealing nothing about your content. Publishing raw bytes alongside an entry exists, but it is an explicit, per-entry opt-in. The default is: the world can verify your record exists; only you know what it says.
A hash — 32 opaque bytes (48 on a SHA-384 log) you compute on your own machine, with the CLI, the SDK, or plain sha256sum. The content itself never leaves your custody, and we could not read it if we wanted to: from the log’s side, every entry looks the same.
It does not mean rewrites are impossible — nothing offers that honestly. It means every new head must prove consistency with the previous one, witnesses re-verify that proof before cosigning, and every receipt, evidence bundle and mirror holding an earlier head can check it again. A rewrite fails those proofs, or shows up as two signed heads that cannot both be true the moment two verifiers compare notes — signed evidence, either way.
Not past a witness you run. An entry’s time is bounded by the cosignatures on the first head that includes it, and each witness refuses a head whose time runs backwards or ahead of its own clock. A new log is cosigned by our witness; require one you run, or a third party runs, and backdating needs a key we don’t hold. A false cosignature would be permanent, verifiable proof against whoever made it.
Nothing. An evidence bundle is self-contained: your hash, the Merkle proofs, the signed head, the cosignatures. It verifies offline against the keys you pinned, with no call to us — this year, or twenty years after the last TillNotary server goes dark. Run a mirror (tilldev notary mirror) and you also hold the full log, every entry checked against its signed root.
No. There are no tokens, no mining, and no consensus protocol. TillNotary is a transparency log in the Certificate Transparency lineage: a single append-only Merkle tree whose operator is checked by witnesses and by anyone who keeps a mirror. You get the verifiability people want from a blockchain at the latency and cost of a normal web service.
You shouldn’t have to — that’s the point. Each log’s witnesses and their keys are published; you pin the ones you trust, and verification is done by your code against those pins. If a witness ever cosigns a bad head, its signature on that head is permanent proof of the failure. Our witness is the default; if it doesn’t satisfy you, run your own with the CLI and require it.
Anchor what matters. Hand every auditor, court, and customer a proof they can check themselves — against keys they pin, on a record no one can quietly rewrite. Not even us.
Same workspace, same login. Anything the other products record, TillNotary can make provable — add what you need when you need it.