A route can be optimal for a snapshot and weaker at execution

A route can be the strongest option under one snapshot and become weaker before it executes. This is a timing distinction: the optimizer selected using one state, while settlement encounters another.

A hypothetical route reversal

At State One, Pool A offers more output than Pool B for the requested amount. The router selects A. Another transaction then consumes part of A's favorable liquidity, while B remains unchanged. At State Two, B would be the stronger choice.

The initial selection can be correct for State One even though a fresh search would now choose B. Conversely, blaming every weak execution on changing state would conceal genuinely poor route selection. Both questions need evidence.

Compare like states

To assess search quality, compare candidate routes using a common state, amount, objective and source set. To assess the user's realized outcome, compare the submitted terms with the settled result. Those are related evaluations, but they are not the same test.

Uniswap's routing configuration includes a block reference for onchain data. Its swap concepts describe differences that can arise while execution is pending.

Why refreshing helps without guaranteeing

A refresh gives the service newer information and can change path selection, allocation or expected amounts. It does not prevent another state change immediately afterward. The actual execution bounds still determine whether the eventual trade remains acceptable.

A route can also change because the service updates a dealer offer, cost estimate or eligibility assumption rather than because the direct pair's visible price moved. A stable chart is not proof that every routing input stayed constant.

For a useful record, retain quote time or state reference, the selected path and final execution data. Without them, a later quote from another service cannot cleanly establish what was available at the original decision point.

The word optimal belongs to a defined problem at defined inputs. Keeping that boundary visible makes both routing claims and performance criticism more accurate.