Swap simulation vs actual execution

A swap simulation evaluates a proposed call against a particular state and assumed transaction context. Successful simulation is evidence that the call can work under those conditions. It is not a reservation of those conditions until a future block.

What the simulation knows

A simulator can model the sender, balances, permissions, contract code and pool state available to it. If the proposed trade violates a condition in that state, it can reveal a failure before submission. Depending on the tool, the context may be the latest block, pending state or an explicitly chosen snapshot.

Ethereum's documentation distinguishes read-style calls from transactions that actually change network state. Uniswap's router repository also includes simulation support in its tooling. Neither makes simulated output a settled receipt.

What can change afterward

A hypothetical simulation at State One finds enough B in a pool to meet the swap's minimum. Before the transaction executes, another trade changes the reserves. State Two may now produce less than the minimum. The earlier simulation can have been correct and the later transaction can still fail.

Account conditions can also change. The input balance might be spent by another action, an allowance might change, or the order's deadline might pass. A mismatch between the simulated caller and real execution context can create a separate discrepancy.

Keep the evidence specific

When reviewing a simulation result, record the relevant state reference, caller, target, input data and assumed value. “Simulation passed” without those details leaves unclear what was actually evaluated.

The practical benefit is reducing avoidable errors under known conditions. The remaining uncertainty comes from state changes, assumptions and inclusion timing. A fresh simulation can reduce the age of the evidence, but it still cannot guarantee future state. The signed or encoded execution bounds remain the rules the actual trade must satisfy.