Re-checking a result against saved responses
How Forensia re-derives what it showed you from the saved bytes, and what happens when the two disagree.
#Plain languageIn plain terms
Storing a response proves what the source said. It does not prove the software read it correctly. A bug could show a transfer that the response never contained.
So Forensia can read its own homework. It takes the saved responses, runs the same interpretation again from scratch, and compares the outcome with what is on screen. If they differ, it says so loudly and blocks exports.
#How it worksHow it works
- Verify each saved response against its fingerprint. Unverified responses are never used.
- Feed the verified responses to the same interpreter that produced the original result.
- Compare the new output with the displayed result, field by field.
- Report matched, conflict, unavailable or check-limit.
No network request is made. Nothing is repaired or rewritten. The check only reads.
#Technical detailThe exact rules
| What is re-checked | What is compared |
|---|---|
| Token steps | Each token event against the saved receipt: kind, sender, recipient, contract, amount, token ID, status. |
| Call steps | Each call frame against the saved trace: position, depth, type, status, failure origin, parties, value, selector. |
| Account changes | The before-and-after diff against the saved state trace, compared as canonical JSON. |
| Historical code | The code shown against the saved code response for the same address and block. |
| Approvals | Each approval event and each approval-then-transfer sequence against the saved receipt. |
| Wrapping actions | The wrap or unwrap amount, account and event against three saved responses. |
| Execution context | Transaction format, reported network and block position against the saved transaction, receipt and block responses. Recorded fee inputs are compared with the transaction and receipt too. |
| Bitcoin allocation | For a confirmed Bitcoin transaction with at most 16 inputs and 16 outputs: each displayed input and output, the fee and the block against the saved transaction response. |
| Outcome | Meaning | Blocks export? |
|---|---|---|
| Matched | Every compared field agrees. | No |
| Conflict | The saved bytes disagree with what is displayed. | Yes |
| Unavailable | Some responses were not saved, so the check is incomplete. | No |
| Check limit | The data exceeds what the browser check will process. | No |
Common rules apply to every check. Responses are decoded as strict UTF-8. The saved request's identifier must match the response's. A response containing an error is never treated as data. A missing response never hides a contradiction in another response.
On a conflict, the Markdown report and the raw evidence export are both blocked, saving the result is disabled, and a banner tells you not to rely on the conflicting interpretation.
#LimitsWhat it does not tell you
- No transaction is re-executed. The check re-reads responses, it does not run the EVM.
- It covers the interpretations listed above. Other findings are not re-derived.
- Unavailable and check-limit leave a result unverified. They do not mean it is wrong.
- It needs the raw responses, so it is not available on the public beta.