How tamper-evident audit logging works
Four steps. Your team never touches crypto — we publish one Merkle root and the maths does the rest.
You send an event
One API call from your existing logging code. A receipt comes back immediately.
We hash it
Thousands of records collapse into one Merkle root. Your data never leaves in readable form.
We anchor it
That root goes on a public chain where nobody can edit it. Including us.
Anyone checks
Your auditor verifies it themselves. No account, no permission, no trust required.
S3 Object Lock stops your staff.
It doesn't stop you.
Write-once storage is good, and if it solves your problem you should use it — it's cheaper than we are. Sigstore/Rekor proves when something existed, for free. Neither proves it without you trusting the account holder. Here are the three rows where that matters.
| Can you prove… | Internal log | S3 Object Lock | Sealtrail |
|---|---|---|---|
| staff didn't edit it | no | yes | yes |
| when it existed | weakly | yes | yes |
| …without trusting you | no | no — you own the account | yes |
| …without trusting the vendor | no | no — trust AWS | yes |
| …after the vendor is gone | no | no | yes |
Those last three rows are the entire product. We're not faster, cheaper or more durable than AWS. We're the only one where verification needs nobody's good faith.
Pricing
Flat subscription, no per-event metering — you shouldn't face a purchasing decision every time you log something.
Starter
- 100k events / month
- Hourly anchoring
- Public verifier
Growth
- 2M events / month
- 15-minute anchoring
- Anchor webhooks
- Your own on-chain namespace
Compliance
- Unlimited events
- 5-minute anchoring
- Auditor export pack
- Self-host option
A receipt, not a black box
You send an event over a REST API and get one of these back. No SDK to adopt, no schema to migrate — and nothing in it asks you to trust that we computed it correctly.
// The shape of every receipt — matches packages/verify's Receipt type, // checked by cross-implementation conformance tests, not just asserted here. { "version": 1, "leaf": "0x68081b59…", "proof": [ { "sibling": "0x9a2f…", "siblingIsLeft": false }, { "sibling": "0x4c11…", "siblingIsLeft": true } ], "root": "0x276fcc7a…", "chainId": 8453, "contract": "0x256080339DEA7E8F3089C49CCEB0F98547103f91", "anchorTxHash": "0x…" } // Fold the proof over the leaf and compare to the root, then confirm the root // was actually anchored on Base at anchorTxHash. Nothing here requires an // account with us, or trusting that we computed it honestly — see the // public verifier for a version that runs entirely in your browser.
Send the same idempotencyKey twice and you get the original event back, not a duplicate. "Did this happen once, or twice?" is precisely the question an audit log exists to answer.
Self-serve API access isn't open yet — try the public verifier against a real anchored receipt, or get in touch to be onboarded directly.
What we deliberately can't do
There is no endpoint to edit an event. No endpoint to delete one. Not "not yet" — they don't exist at the API, in the database layer, or in the contract, and there are tests that fail if anyone adds them. The contract has no owner, no admin and no upgrade path.
That binds us as tightly as it binds you. Need to correct a record? You append a correction — which is what an audit trail is for. We'd rather be unable to help you rewrite history than be asked to.