HOW THIS WORKS
Records you can trust without trusting us.
Most "audit log" tools ask you to take the vendor's word that nothing has been changed. Tamperproof is built so that nobody — not your IT team, not a malicious database admin, not us, not even a court order against us — can silently alter a record once it's written. If anything is changed, anyone with the document can prove it.
The promise, in three lines
- Server time and authorship are stamped at the moment of recording — never the user's clock.
- Every record is cryptographically linked to the one before it. Removing or rewriting one row breaks the rest of the chain in a way anyone can detect.
- The chain is anchored externally every minute by an accredited timestamping authority and to the Bitcoin blockchain. Even if our company disappeared tomorrow, those proofs would still verify.
Why even we can't forge a record
The signing key that makes a record valid lives only inside our edge runtime memory — it's never written to the database. To forge a record we'd have to compromise that key, then also produce a valid hash chain link to the previous record, then also produce a valid Merkle batch root, then also convince an independent timestamping authority and Bitcoin to retroactively endorse our forgery.
It's not that we promise we won't tamper. It's that we built the system so that even we don't have the privileges to tamper without being detected.
What happens behind the scenes
You record an entry
Your browser sends the content. Our edge worker stamps it with the server time and your authenticated identity, signs the canonical bytes with an Ed25519 key we hold in memory only, and hands it to the database.
The database links it into the chain
Inside the database, before we even store the row, we re-verify the signature. We compute a SHA-256 hash that includes the previous record's hash, your record's content, and the server's timestamp. If anyone alters any of those after the fact, the hash no longer matches.
Once a minute we externalize the proof
A scheduled job collects all new records into a Merkle tree and asks two independent witnesses to vouch for the root:
- RFC 3161 Time Stamping Authority. A countersigned receipt from an accredited TSA — the same kind of signature used in EU eIDAS-qualified electronic signatures and U.S. ESIGN/UETA workflows.
- OpenTimestamps / Bitcoin. A receipt that's folded into a Bitcoin block within ~1–6 hours. It costs nothing, it's verifiable forever, and nobody — not even Bitcoin's developers — can rewrite the block once it's confirmed.
Both receipts are stored in immutable object storage with versioning enabled, so any later overwrite leaves a tamper-evident trail of its own.
You — or anyone — can verify it offline
The PDF you export from any record carries the entire proof bundle. Drag it onto our verifier, or use the open-source
openssl ts -verifyandots verifycommands without ever talking to our servers. The math is the same either way.
What if…
What if someone hacks Tamperproof?
An attacker who breached our infrastructure could try to inject new records or alter existing ones. They'd be stopped by:
- The signing key — only present in edge worker memory, never on disk, never in the database. A storage-layer breach can't sign anything.
- The hash chain — altering an old record breaks the link to every record that came after.
- The external anchors — the RFC 3161 receipt and the Bitcoin block already commit to the chain head as it was. They can't retroactively endorse a different chain head.
So at worst, an intruder could try to add records going forward (which would fail signature verification anyway). They cannot rewrite history.
What if a database admin (ours, or yours) tries to alter a record?
The database tables have UPDATE and DELETE revoked from every role; the only way to write is through a function that requires a valid signature from the edge worker. A direct UPDATE issued as a superuser bypasses that check, but the row's record_hash would no longer match the chain's recomputation, the next record's prev_hash would no longer link, and the Merkle leaf for that record would no longer match the externally-timestamped batch root. The verifier flags it instantly.
What if the company is compelled by law to alter a record?
We can't. To make a forged record verify, we'd need to forge the chain link, the Merkle path, the TSA's countersignature, and the Bitcoin block proof. The first is hard, the next three are out of our reach entirely.
What we can do under legal compulsion is hand over the data we have, or refuse to serve our website. We cannot make a falsified record check out as genuine.
What if the company shuts down?
The proof bundles are self-contained. The PDF you exported today will still verify a decade from now using openssl ts -verify against the TSA's published certificate, and ots verify against the Bitcoin blockchain — neither of which depend on us being alive. The only thing that goes away is the convenient web verifier; the underlying cryptography doesn't.
What if someone modifies a PDF after it's exported?
The PDF embeds a cryptographic fingerprint of its content. Our public verifier extracts that fingerprint and re-checks it against the chain. If the visible content has been edited but the embedded proof wasn't updated (and it can't be — the signature would no longer match), the verifier shows "tampered" and the original record's owner gets an alert.
How do you know the timestamp is real and not just our clock?
The server-issued created_at alone is just our clock — and you'd be right not to trust it on its own. That's why every minute we get the chain head countersigned by an accredited Time Stamping Authority (RFC 3161, the same standard used in EU eIDAS qualified signatures) and submit it to OpenTimestamps for inclusion in a Bitcoin block. Both witnesses are independent of us. As soon as a Bitcoin block confirms, anyone in the world can prove the record existed before that block.
Try it
Pick any record you've made, click Export PDF, then drop the PDF onto the verifier — with or without signing in. You'll get a green "verified" or a red "tampered" verdict in under a second. Edit the PDF in any tool and re-upload it: you'll see the verdict flip.