---
icon: droplet
---
# Most Liquid
The Most Liquid algorithm finds swap routes by enumerating candidate paths, scoring them with a cheap heuristic, then simulating only the most promising ones. It trades completeness for speed: it won't evaluate every possible route, but it finds good routes fast.
## Overview
The algorithm runs in four stages:
1. **Enumerate** all simple paths up to `max_hops` using BFS
2. **Score and sort** paths by a heuristic (spot price and liquidity depth)
3. **Simulate** the top-N paths using actual pool math
4. **Rank** by net output after gas cost deduction
The key insight is that stages 1-2 are cheap (graph traversal and arithmetic), while stage 3 is expensive (full AMM simulation per hop). The heuristic in stage 2 acts as a filter, ensuring simulation budget is spent on paths most likely to win.
## Stage 1: Path enumeration
Starting from the source token, BFS explores all outgoing edges up to `max_hops` depth. At each step it follows every edge (including parallel edges between the same token pair from different pools), building complete paths from source to destination.
The result is a list of all simple paths (no repeated tokens) from source to destination within the hop limit.
## Stage 2: Heuristic scoring
Each path is scored without simulation using two derived data values per edge:
* **Spot price**: the marginal exchange rate at zero trade size (includes pool fees)
* **Depth**: the pool's available liquidity in USD terms
The score for a path is:
```
score = (product of spot prices along the route) × min(depth along the route)
```
The spot price product estimates the exchange rate. The minimum depth acts as a bottleneck indicator: a path is only as liquid as its shallowest pool. Paths through deep, well-priced pools score highest.
This scoring is approximate. It ignores price impact (the spot price assumes infinitesimal trade size) and doesn't account for how liquidity changes after each hop. But it's fast and good enough to rank tens of thousands of candidates so the expensive simulation stage focuses on the right ones.
Paths are sorted by score descending. If `max_routes` is configured, only the top-N proceed to simulation.
## Stage 3: Simulation
Each surviving path is simulated end-to-end. For every hop, the algorithm calls `get_amount_out()` on the actual pool state with the running amount from the previous hop. This accounts for:
* Price impact at the exact trade size
* The pool's fee structure
* Tick crossings (Uniswap V3) or other non-linear mechanics
* Reserve state as of the latest block
If a simulation fails (e.g., insufficient liquidity in a pool), the path is discarded. Otherwise, the final output amount is recorded.
## Stage 4: Gas-adjusted ranking
Each simulated path's output is adjusted for gas cost:
```
net_output = gross_output - (total_gas * gas_price * token_price_ratio)
```
Where `total_gas` is the sum of gas estimates for each swap in the route, `gas_price` is the current block's gas price, and `token_price_ratio` converts the gas cost (in the native token) to the output token.
The path with the highest `net_output` wins.
> **Note:** `route.total_gas()` is a fast, approximate estimate used for ranking paths *within* this algorithm. When multiple worker pools compete, the `WorkerPoolRouter` applies a more accurate gas estimate (`estimate_gas_usage` from tycho-execution, which accounts for token transfers and router overhead) before the final cross-pool ranking.
## When it works well
* **Common pairs** (WETH/USDC, WETH/WBTC): a few high-liquidity pools dominate, and the heuristic reliably ranks them correctly.
* **Low hop counts** (2-3): the path space is small enough to enumerate exhaustively, so the heuristic filter drops very little.
* **High-frequency quoting**: the algorithm is fast enough to serve latency-sensitive integrators.
## When it struggles
* **High hop counts** (4+): the number of candidate paths grows exponentially. Even with `max_routes` capping simulation, the heuristic may not surface the best path.
* **Exotic pairs**: tokens with thin liquidity often have non-obvious routes where the spot price heuristic misjudges the actual output. The Bellman-Ford algorithm, which simulates every edge without a heuristic filter, handles these better.
## Suggested configuration
```toml
[pools.most_liquid_3_hops]
algorithm = "most_liquid"
num_workers = 3
task_queue_capacity = 1000
max_hops = 3
timeout_ms = 500
max_routes = 50
```
* `max_hops = 3` keeps enumeration tractable. At 4+ hops the candidate path count explodes and the
heuristic filter starts dropping good routes.
* `max_routes = 50` caps the simulation stage. Without it every enumerated path is simulated, which
is what makes high hop counts expensive.
* `timeout_ms = 500` leaves headroom for the simulation stage on VM-simulated protocols. Lower it if
you run this pool purely as a latency-sensitive baseline.
{% hint style="warning" %}
**Set connector tokens.** With `connector_tokens` unset, routes can pass through illiquid long-tail
intermediates, which raises reversion risk. Restrict intermediate hops to a small trusted set —
generate one for your chain with `fynd derive-connector-tokens --chain Ethereum --top-n 10 --output
toml` and paste it into the pool. See
[Connector tokens](../guides/server-configuration.md#connector-tokens).
{% endhint %}
## Source reference
| `fynd-core/src/algorithm/most_liquid.rs` | Algorithm implementation |
| `fynd-core/src/algorithm/mod.rs` | `Algorithm` trait definition |
| `fynd-core/src/graph/petgraph.rs` | Graph implementation (petgraph::StableDiGraph) |
| `fynd-core/src/worker_pool/registry.rs` | Maps `"most_liquid"` to `MostLiquidAlgorithm` |
| `worker_pools.toml` | Worker pool configuration |