Try Realtime Audit on your own data.

Your files never leave this browser. No upload, no account, no tracking. Close the tab and everything is gone.

Loading the engine…

No files to hand? See the sample case or use the templates below.

1 Drop your own files

Two files: causes and changes. CSV or JSONL. ·

Causes one row per event allowed to move a balance, from two or more independent services Drop a file or click to choose Changes one row per write to a balance Drop a file or click to choose

Causes: id · type (deposit, withdrawal, fill, transfer, fee) · account · asset (optional) · amount (signed) · time · producer (the service that issued it) · ref (optional)

Changes: account · asset (optional) · delta (signed) · time · source (where the write was observed)

Common alternatives such as user_id, currency or timestamp are recognised. Anything else, you map after the first run.

Window Grace, s Check amounts Require a cause id

Producers and cause types

Trusted producers comma-separated; empty trusts every producer Derived cause types must have a root cause for the same balance in the window Root cause types Cause chains a cause from several independent services, root first, one chain per line (e.g. the user frontend's request, then the backoffice approval). The last stage justifies a write only if its ref leads back through every stage. Stages are joined by id, so an approval hours after the request is fine. Single-account cause types an id of these types may move one balance only; on a second account it is a reused cause

Measured: about 3.8 s for 27 MB of input, 16 s for 135 MB. Above roughly 150 MB a browser tab may run out of memory; run the same check offline instead, with the audit CLI.

Sample case: a withdrawal needs a request and an approval

Already run for you, so you can see what a finding looks like. Two independent services write the causes: the user frontend records the user's request (withdrawal.requested), the backoffice records the admin's approval about an hour later (withdrawal.approved, pointing at the request in ref). A payout is justified only when both exist, agree, and the request has not been approved before.

A-1 approves request R-1: correct.
A-2 approves R-1 again: one request, two payouts.
A-3 approves R-404, which nobody requested: an admin paying out alone, or a replay under a new id.
A-4 approves 40,000 on a request for 4,000.
A-5 approves a "user request" that the backoffice wrote itself.

Without the request as a second source, each approval would justify itself and none of the last four would show.

causes.csv

changes.csv

Check that nothing leaves

You don't have to take our word for it.

Network tab. Open your browser's developer tools, then drop your files. You'll see no request go out.
Offline. Load this page, turn off your network, and run it again. It works.
Policy. The page's Content-Security-Policy sets connect-src 'none': the browser itself refuses any request from this page's code. View the source to see it.
Source. The engine is open, at commit 4a73fd7. Build it with go1.27.1 and compare the hash below with the one your browser computed from the bytes it is running.

engine sha256 (published): 98dea95d4f263950953b8d47169c204e25793e3b49ff643415f23154b6508268
engine sha256 (computed here): …

What this trial is, and isn't

It runs the same check as the product, on what you give it. It isn't an audit: nobody reviews the result, and nothing is signed.
Mapping a real export onto these two files is usually the hard part. If your export doesn't fit cleanly, that's the most useful thing to learn here.
A partial export produces partial findings. Some "findings" on partial data are gaps in the export, not in the ledger.

Book an audit-only review How it works

Try Realtime Audit on your own data.

1 Drop your own files

2 Read the result

Sample case: a withdrawal needs a request and an approval

Check that nothing leaves

What this trial is, and isn't