Testing transaction simulation at scale, part 1: accuracy

Transaction Shield simulates every transaction before you sign it, in plain terms: what leaves your wallet, what comes back, and what you're approving for later. This post is about how we test that the simulation is actually right.

A simulation you can't trust is worse than no simulation at all — it tells people to sign with confidence they shouldn't have. So before we show a user “you will receive 0.5 ETH,” we need that number to be correct across thousands of contracts we didn't write and can't control.

What we simulate against

We replay every incoming transaction against a forked copy of the destination chain's current state, execute it exactly as it would run on-chain, and diff the resulting balances. No heuristics, no guessing at intent from a function name — just the real state transition, computed before you've signed anything.

Where accuracy breaks down

• ▸Contracts with time-dependent logic, where the result changes block to block
• ▸Multi-step routes through several protocols in a single transaction
• ▸Proxy contracts that change behavior after being simulated

Each of these gets its own regression suite, replayed against historical mainnet transactions where we already know the ground truth. If our simulated result doesn't match what actually happened on-chain, that's a bug, not an edge case.

Coming in part 2

Part 2 covers how we turn a raw simulation diff into the plain-terms summary a person actually reads before signing — and why that translation step is where most of the remaining risk lives.