Saving trace progress and bridge checks apart from the original result

A lookup gives you one captured result. The work that follows is different in kind: you check where a recipient sent funds next, follow a spent Bitcoin output, or look for the other half of a bridge transfer. Each of those is a new observation, made later, with its own sources.

Until now that follow-up work lived only in the open page. Forensia can now keep it as a separate checkpoint: a saved record of the checks you ran, attached to the exact result they started from. You can reopen it later without asking any source again, download it as a file, and import that file somewhere else.

These checkpoints are stored in your browser only. They are not sent to a server, not encrypted and not synced between devices. Clearing browser data, or the browser evicting storage, removes them. A downloaded backup is the only copy that survives that.

#Plain languageA lab notebook kept beside the original photograph

Picture an investigator with a dated photograph of a scene and a notebook of the follow-up visits made afterwards. The photograph is never retouched. Each visit gets its own dated entry, including the visits where nobody answered the door.

A checkpoint works the same way. The original result is stored inside it unchanged, with its original capture time. Each follow-up check is appended as a step, whether it produced a result or failed. Reopening shows that history as it was recorded. It does not refresh anything and does not tell you the current state of the chain.

Four kinds of follow-up work can be kept this way, each in its own list: native-coin recipient checks on EVM networks, token recipient checks on EVM networks, Bitcoin spent-output checks, and Across bridge checks between Ethereum and Base.

#How it worksSaving, reopening and backing up a checkpoint

Saving a checkpoint is a different action from Save result. Save result keeps the original capture and your notes. It does not keep your place in a trail or any separate recipient check.

1. Run a follow-up check. On an EVM result, open Follow captured transfers and check a recipient. On a Bitcoin transaction, open Follow spent outputs. On an Ethereum or Base transaction, run Check Across journey on Overview.
2. Save it with the matching control: Save EVM trace, Save token trace, Save trace (Bitcoin) or Save bridge check.
3. Open Saved in the left rail. The lists are marked Browser only: Saved investigations, Saved EVM traces (with Token traces inside it), Saved Bitcoin traces and Bridge checks.
4. Choose Reopen EVM trace, Reopen token trace, Reopen trace or Reopen on a bridge check. The original result and the saved steps load from the browser. No source is queried.
5. To keep a copy outside the browser, prepare a backup (Prepare native backup, Prepare token backup, Prepare Bitcoin backup, or Prepare JSON backup for a bridge check) and use the download link that appears.
6. To restore, use the import control in the matching list, for example Import EVM trace backup or Import bridge backup, then reopen the imported item.

After a trace is saved, later checks on it are recorded before they run and their results are saved automatically. An unsaved trace stays temporary. Removing a checkpoint asks for confirmation and removes only that item from this browser.

#Technical detailRecord formats, storage and import rules

Where the records live

Each kind has its own IndexedDB database and object store, keyed by record ID. Separate browser origins have separate stores.

Every store holds at most five records and 10 MiB in total. Where a store has two schemas, the first is a completed-steps checkpoint and the second is a journal that can also hold a pending attempt. Both share the same allowance.

What a record contains

schema: "forensia.evm-native-trace-backup.v1"
id: string                      // snapshot digest of the original capture
revision: number
savedAt: string
startingInvestigation: InvestigationNotebook
branches: { rootTransactionHash, journal: NativeTraceAttempt[] }[]
selectedRootTransactionHash: string
stateDigest: string             // SHA-256 over canonical JSON of the state

For trace checkpoints the record ID is the snapshot digest of the original capture, so the checkpoint is bound to exactly one result. The embedded investigation must contain exactly one capture and no review entries. A native record holds one to four starting transfers, each with a journal of attempts, and at most four attempts across all of them. A Bitcoin record holds a single journal where each step is either a capture or a failure for a given txid.

A bridge check is bound differently. Its ID is SHA-256 over canonical JSON of the original snapshot digest together with the whole observation, including the interpreted relay and execution fields. A new check of the same transaction is therefore a new record with a new identity, never an update.

What import verifies

• Size and shape first: the byte limit, a nesting depth limit of 36, and an exact set of allowed top-level keys. Unknown fields are refused.
• Keys named __proto__, prototype, constructor, rawEvidenceBundle or vault are refused anywhere in the file. Raw source responses cannot be imported through a backup.
• The digest is recomputed over canonical JSON and must equal the stored stateDigest (journalDigest for a Bitcoin checkpoint).
• The queue is rebuilt, not trusted. Import replays the journal against the original capture and recomputes which recipient or output comes next and which outputs matched. Queue and match flags in a file are not accepted as fields.
• For a bridge check, the original capture must be an Ethereum or Base transaction, and the observation passes the same admission as a live response: expected transaction and block, source IDs, request hashes, relay identity, execution terms and manifest.

Write rules

Validation completes before the storage transaction opens. The guard and the write then run inside one IndexedDB read-write transaction: the store is read with getAll, the new record is checked against what is there, and only then is it written. A trace update must carry the revision the page last saw, increment it by exactly one, keep the embedded original investigation identical under canonical JSON, and leave every earlier journal step unchanged. A mismatch aborts the transaction with a message that the trace changed in another tab.

Bridge checks are insert-only. Writing an identical package again is a no-op, and a different package can never overwrite an existing one. Removal requires the content digest the page currently holds, so a record changed or removed in another tab is not deleted blindly.

Database version 2 for the three trace stores exists for one reason: an older copy of the application that opens version 1 fails with a version error instead of overwriting a newer journal. If an older tab is still holding the database open, the save is refused with a request to close older Forensia tabs, and the existing record is left byte-for-byte unchanged.

Recorded file recovery examples

The engineering notes record four file round trips into a separate, empty browser origin on 6 October 2026: a token trace rooted at Ethereum transaction 0x22fc4a1bba0e2a711a5852f5c835eea4cb764f989895b1b48ec73d84dab8ed95, a Bitcoin trace rooted at f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16, a native trace rooted at 0x351035eb60de36d50a6d491308a03971a0b8d68975610177de908e4eb96b555f, and the bridge check for Base transaction 0x60c7220dd59650ff4bde20ab4cafb34f21d56bfeab645de77132e5d8a354213d. In each case the original capture time survived unchanged and used attempts were retained, not reset.

#LimitsWhat a saved checkpoint is not

• Browser only. Not encrypted, not synced, not stored by Forensia. Browser clearing or eviction can remove it.
• No raw source responses. Backups carry references and hashes. Raw evidence stays unavailable in a browser that only imported the file.
• Not a current-status check. Reopening does not contact any source and does not confirm that the recorded blocks are still canonical.
• Not part of Save result or its report. A checkpoint does not add anything to the source manifest of the original capture.
• Markdown bridge reports are for reading. Markdown is not an import format.
• Saving does not widen a trace. The limits of the underlying checks (four attempts, two hops) are unchanged, and a saved trace is not a complete history, a proof that the same funds moved, or a statement about who controls an address.
• Not certified across physical devices, assistive technology, real disk exhaustion or crash and power-loss conditions. Those acceptance checks remain open.