import JSBI from 'jsbi';
/**
 * Per-protocol caps on how many candidate routes are sent for on-chain quoting.
 *
 * With "heavy" pool selection (many `topNWithEachBaseToken` etc.), the candidate
 * pool set can produce 200+ routes per protocol. Each route × `distributionPercent`
 * grid is one Multicall3 sub-call. Multicall3 sub-calls run **sequentially** inside
 * a single `eth_call` on the node, so wall time for a protocol's quote phase is
 * bounded below by `(routes × amounts × per_quote_time) / parallel_chunks`.
 *
 * Capping route count is the highest-leverage way to reduce that wall time
 * without changing the user's pool-selection heuristics. We sort routes by depth
 * (1-hop > 2-hop > 3-hop) and within each depth by the minimum pool liquidity
 * along the route — preferring deeper, shorter paths that are far more likely
 * to produce a winning quote than long, thin ones.
 *
 * The defaults below are conservative; PV4CL/PV4BIN already enforce 80 internally.
 */
export declare const V3_MAX_ROUTES = 80;
export declare const V4_MAX_ROUTES = 80;
export declare const PV3_MAX_ROUTES = 80;
/**
 * Generic route-capping helper. Works on any route whose `pools[]` items have a
 * JSBI `liquidity` field (V3, V4, PV3 all qualify).
 */
export declare function capRoutesByLiquidity<R extends {
    pools: ReadonlyArray<{
        liquidity: JSBI;
    }>;
}>(routes: R[], maxRoutes: number): R[];