Bound route search work in the PancakeSwap SDK

A route search needs a computational budget. More hops, split paths and candidate pools can increase work without guaranteeing a meaningful improvement for the user.

PancakeSwap's Smart Router reference exposes controls such as maxHops, maxSplits, allowedPoolTypes and distributionPercent. Treat their documented meanings as version-specific and keep the chosen values in reviewed configuration.

Measure before tuning

Create a representative set of token pairs and trade sizes, including sparse and dense liquidity. Measure discovery time, quote RPC time, search time, resulting output and estimated execution cost separately. A slower search that improves gross output can still be less attractive after gas.

These are proposed evaluation criteria, not benchmark results. Do not publish a universal faster or better claim based on one token pair.

Protect the interface

Move expensive work away from the browser's main rendering path when the architecture allows it. Bound concurrent route searches and cancel superseded requests. A user typing another digit should not queue a full backlog of obsolete searches.

Apply a global deadline to the operation. If the budget expires, return a clearly identified partial or unavailable result according to your product policy. Do not call a budget-limited result mathematically optimal across an unsearched universe.

Preserve restrictions

A fallback search may narrow the work, but it should not silently enable pool types or source categories the user disabled. Keep those restrictions separate from performance knobs.

Regression fixtures should include a route available only through an extra hop and another requiring a split. They reveal what capability is lost when limits tighten. Record that tradeoff in the rollout decision rather than tuning solely for lower average latency.