Sooner or later somebody asks. An auditor wants to know who had access to a client file in March. A regulator asks when a record was disclosed and to whom. A former client's lawyer asks whether a document was ever sent at all. The answer is expected in writing, and it is expected to be checkable.
Most businesses answer from application logs — files that an administrator can edit, that a vendor can rotate away, and that carry no evidence they have not been changed. They are usually accurate. The problem is that accuracy and provability are different things, and only one of them survives being questioned by someone who has a reason to doubt you.
This service gives you a record built the other way round. Every movement writes one entry, and every entry commits to the entry before it, so altering a single line breaks every line that follows. You can export the whole chain, verify it yourself or hand it to someone who will, and answer the question with arithmetic instead of assurance.
Six events in a genuine hash chain. Each block’s fingerprint is computed here, in your browser, from the line you can read — prefixed with its parent’s fingerprint. Change one word in one block and watch what happens to every block after it.
Every event field below is editable. One letter is enough.
The hashes above are real SHA-256 digests, not decoration. An exported chain behaves exactly this way in a verifier you write yourself.
A live simulation of the audit stream, running on your own clock. Hover any entry to light its lineage upward; click to expand the full attestation record.
Open an envelope to read it. It stays open — a desk of read correspondence is exactly the mental model we want you to leave with.
Every seal, relay, open, rotation and attestation writes one entry, and every entry commits to the hash of the one before it. Rewrite a single line and every downstream hash stops matching. The chain is exportable in full via GET /v1/audit and verifiable without us.
envelope opened →Rotation is a first-class, metered, attested event — not a maintenance window. Old key-pairs enter a read-only grace period so in-flight envelopes still open, new envelopes bind to the new key immediately, and the rotation itself is written to the audit chain with its quorum record.
envelope opened →The export is a chained log covering the period you ask for. Each line records what happened, to which envelope, at what time, and the digest of the line before it. Because each digest depends on the entire history behind it, a single edited character anywhere in the file makes every subsequent line fail verification — and the failure points at the exact line that changed.
Nothing in the export contains the contents of anything. It records that a sealed object moved, not what was inside it — so the file can be handed to an auditor, a regulator, or the other side of a dispute without disclosing a single client document in the process.
You can pull the chain yourself at any time from GET /v1/audit, or ask us for a signed evidence package covering a named period. Verification is arithmetic anyone can run: re-hash each line, compare it to the next line's parent, and stop at the first mismatch. If there is no mismatch, the history in your hands is the history that was written.
In practice, most reviews end here. The question is rarely "do we believe you" — it is "can you show it", and this is the showing.
// each line commits to the one above it
14:02:07 env_9f42a1c7…c1a7 sealed
origin web-form.intake
commit 0x8c31…f19d
parent 0x2ab7…0c41
14:02:07 env_9f42a1c7…c1a7 relayed
bytes 18,204
commit 0xd0f2…4c19
parent 0x8c31…f19d
14:06:51 env_9f42a1c7…c1a7 opened
peer ops-dashboard.client
attest ✓ mutual
commit 0x3fa9…aa14
parent 0xd0f2…4c19
02:00:00 keypair_relay-egress rotated
quorum 2-of-3
commit 0x1e77…d5b8
parent 0x3fa9…aa14Figures in this excerpt are illustrative. A real export is continuous, covers every event in the period, and arrives with the chain head printed on the statement so a document you already hold pins the history before it.