Backrun, explained without the jargon

User guide

Written for the person who has to actually stand in front of an auditor, a regulator, or their own board and say "here's the proof" — not for the engineer who built it. No blockchain knowledge assumed, and nothing here says more than what's actually true.

What problem this solves

An audit log is only useful as evidence if the person questioning it can trust that it wasn't quietly changed after the fact. Here's the uncomfortable part: if you also control the database that stores your audit log — and you do, because it's your company's database — then any outside party checking your evidence is really just trusting you not to have edited it. A skilled outsider can't tell the difference between "this record is genuinely untouched" and "someone with database access fixed it up before handing it over."

"Write-once" cloud storage (like AWS S3 Object Lock) helps, and it's worth using — it stops your own staff from editing a record after it's written. But your company still owns the cloud account. An auditor checking a write-once record is now trusting your cloud provider, or trusting that nobody at your company with account access intervened. The trust requirement moved; it didn't go away.

Backrun removes it. When you log an event with us, you get back a small piece of cryptographic proof (a "receipt"). Periodically, we take a batch of these and publish one combined fingerprint to a public ledger — a blockchain — that no single company, including us, controls or can edit. Anyone holding your record and its receipt can run a short, published calculation and get a definite yes-or-no: was this exact record part of what was published, unchanged, by this date? They don't need an account with Backrun. They don't need to trust Backrun's staff, servers, or good intentions — the check works even if Backrun disappeared entirely tomorrow.

In one sentence

We can't make your records true. We can make it so that once you've logged one, nobody — including us — can quietly change it without anyone being able to tell.

Handing a receipt to an auditor

Give them three things:

The original record — whatever you logged (e.g. "Bob deleted record #4471 at 09:04").
Its receipt — the JSON we returned when the record was anchored. Your system should keep this alongside the record itself.
A pointer to how to check it — either our published verification specification for their own engineers to run, or a basic block-explorer lookup anyone can do without writing any code (see the last step below).

What a technically-minded auditor (or someone on their behalf) actually checks:

Recompute the record's fingerprint and confirm it matches the one named in the receipt. If your record was altered in any way — even a single character — this step fails, loudly.
Fold the receipt's proof — a short published calculation, not guesswork — and confirm it arrives at the "root" value named in the receipt.
Look that root up independently, on a public blockchain explorer such as basescan.org — a website with no relationship to Backrun — and confirm it was really published, on the date claimed, by the address named in the receipt. This is the step that requires trusting nobody: basescan is simply reading the same public record anyone can read.
Confirm the receipt points at Backrun's actual contract (0x2560…3f91 on the Base network) rather than some other address — a valid-looking proof pointed at the wrong place proves nothing.

If your auditor's team would rather not do this by hand, our verification docs are written precisely enough for any competent engineer to turn into a script in an afternoon — that's deliberate; it's meant to be independently reimplementable, not something you have to take our word for either.

What we can and cannot prove on your behalf

We'd rather you know the honest boundary now than have an auditor find it for you.

We can prove

A specific record, exactly as it was given to us, existed in that exact form no later than a specific, independently-checkable date.
Nobody — including us — altered that record after that date without it being detectable. There's no mechanism by which Backrun's own staff could quietly revise it, even under pressure, by mistake, or if compelled to: the underlying contract has no function that does that, for anyone.

We cannot prove

That the record is true. If your own system logged the wrong person, or the wrong reason, we faithfully preserve that mistake. We can tell you a record wasn't altered — never that it was accurate to begin with.
Who really did something. We don't verify real-world identity. The "actor" on a record is just a piece of data we protect from tampering, the same as every other field — not something we've independently confirmed.
That nothing was left out. We can prove a record you gave us is genuine and unaltered. We have no way to prove you gave us everything that should have been logged — that a missing event is actually missing is something only your own process can guarantee.
Compliance with any specific standard, by itself. This is one piece of evidence a wider compliance program — SOC 2, ISO 27001, or German GoBD retention rules — can lean on. It is not a certificate that replaces the rest of that program: for GoBD specifically, you still need proper process documentation and correct retention handling on your own side, and we never claim otherwise.
That we're better storage than what you already use. If all you need is "my own staff can't quietly edit this," plain write-once cloud storage already does that, and does it more cheaply than we do. The one thing we add — the only thing — is that checking the claim doesn't require trusting your IT department, your cloud vendor, or us.

Erasure requests: what happens, what survives

If someone exercises a right to erasure (for example, under GDPR) over a record you logged with us, here is exactly what happens:

We remove the record's actual content, and a secret value tied specifically to it, from our systems — in a way that makes reconstructing what the record said computationally infeasible from anything that's left, not merely inconvenient.
Everything else you (and every other customer) logged around the same time is undisturbed — erasing one record doesn't touch the proof for any other.
The receipt for the erased record still proves that something was recorded and published at that point in time. It stops being able to reveal — to us, to you, or to anyone — what that something was.

Two honest limits

This is erasure on our side, not anonymisation everywhere. Your own systems — the application that generated the record, your logs, your support tickets — usually still hold the same underlying facts. Erasing our copy doesn't erase yours; you're still responsible for handling the request across your own systems, exactly as you would be if Backrun weren't involved at all.

One category of record is an exception. If you told us a record falls under German tax-retention law (the GoBD / §147 AO rules), we refuse to erase it until the legally required retention period has passed. This isn't something we invented — data protection law itself carves out an exception for records a legal obligation requires you to keep. It only applies to records you specifically flagged that way; everything else erases normally, on request.

There is currently no self-serve "erase this record" button in the product — contact us and we'll process the request. See erasure & retention in the technical docs if you or your engineering team want the exact mechanism.

Want the engineering-level version?

Everything above has a precise, reimplementable technical specification behind it — start at the documentation hub, or go straight to the verification algorithm.

Impressum