Saved traces and recovery
How multi-step traces are stored in your browser so an interruption never loses work or quietly retries.
#Plain languageIn plain terms
A trace takes several steps, and each step uses part of a small allowance. If your connection drops halfway through a step, two bad things could happen. The work could be lost. Or the tool could retry by itself and spend your allowance twice.
Forensia avoids both. It writes down that it is about to do a step before it does it. If something goes wrong, that note is still there when you come back, and you decide what happens next.
#How it worksHow it works
- Record a reservation: "about to check this address".
- Save the reservation to the browser. If that save fails, nothing is sent.
- Run the check.
- Record the outcome, success or failure, against the reservation.
- Save again.
On reopening a trace, a reservation without an outcome shows as pending. It still counts against the allowance. You can keep an unsaved result if the page still has it, or mark the attempt as interrupted. There are no automatic retries anywhere.
The reservation step starts once a trace has been saved ("Save EVM trace", "Save token trace", or "Save trace" for Bitcoin). Before that, progress lives only in the open page and is lost on reload. The four-check allowance applies either way.
A running check has a "Cancel check" button. Cancelling while the browser verification is still pending stops the wait, and a verification token that arrives late is never used to send the check. In a saved trace, a check cancelled after its reservation was saved is recorded as interrupted and stays counted. In an unsaved trace, a cancelled check is recorded as a failed attempt and also counts. A request that had already been sent may still count toward source limits.
#Technical detailThe exact rules
Traces are stored in the browser's IndexedDB, in separate databases for native traces, token traces, Bitcoin traces and bridge checks. They hold metadata and fingerprints, not raw responses.
| Limit | Value |
|---|---|
| Traces kept per kind | 5 |
| Size per trace | 3 MiB (2 MiB for Bitcoin) |
| Total size per kind | 10 MiB |
| Events in a recovery journal | 8 (a reservation and an outcome for each of 4 checks) |
Append-only history
A saved trace can only grow. Each write must add exactly one event and advance the revision by exactly one, with everything earlier unchanged. A write that expects an older revision is refused, which protects against two tabs overwriting each other. A trace with recovery history cannot be replaced by an older backup.
What is checked when a trace is opened or imported
- Size and nesting depth are within limits.
- Only known fields are present. Raw response data is refused.
- The digest over the trace's contents recomputes to the stored value.
- The embedded starting result passes its own integrity checks.
- The whole trace is replayed from the start. Each recorded step must be the exact step that would have come next.
Queue positions and match conclusions are never read from a file. They are recomputed during the replay. A file that skips, reorders or repeats a step is rejected.
#LimitsWhat it does not tell you
- Anyone who edits a backup file can recompute its digests. Treat an imported trace as a claim to check, not as proof.
- Storage is in one browser, unencrypted and not synced. Clearing site data removes it.
- Reopening a trace does not refresh it or confirm its blocks are still canonical.
- An interrupted attempt stays counted. That is deliberate, so the allowance cannot be reset by closing the tab.