Give PancakeSwap Smart Router reliable pool inputs

Local routing requires a pool universe and current execution data. Token addresses alone are not enough to evaluate multi-hop or split routes.

The Smart Router documentation shows candidate-pool retrieval, a pool provider, a quote provider and gasPriceWei as inputs to route search. Its current EVM imports use the smart-router/evm subpath; pin and verify the package version used in your project.

Separate discovery from quoting

Discovery determines which pools can be considered. Quoting evaluates the candidates for the amount and state in question. A stale discovery cache can omit a useful pool, while stale quote state can misprice a pool that was correctly discovered. Monitor those failure modes separately.

Verify every token object's chain and decimals before constructing CurrencyAmount. A token object from another chain can produce plausible-looking math while referring to an irrelevant deployment.

Keep inputs coherent

Use a verified RPC on the intended chain. Record the state context of important reads where possible. Supply gas assumptions appropriate to the same chain, because route ranking can change when a more complex route costs more to execute.

A static pool provider is a container for prefetched data, not a promise that the data will refresh itself. Define when it is rebuilt and what happens if a pool read fails.

Validate the handoff

After getBestTrade returns, inspect the trade and build calldata with the intended recipient and slippage. Use the matching router deployment and simulate before submission.

A useful fixture supplies no candidates, one failed pool read and a token object with a wrong chain. The application should report a specific unavailable or configuration state instead of constructing a trade from incomplete assumptions. No route found within the supplied pool set is not proof that no liquidity exists anywhere.