Why 1inch May Not Route Through Certain Liquidity Pools

1inch can only route swaps through liquidity sources that Pathfinder supports. A liquidity pool may offer a competitive price or hold substantial liquidity and still be unavailable for routing if its pool type, execution logic, or associated hook is not supported by 1inch.

Pathfinder is 1inch’s discovery and routing algorithm for finding efficient token swap paths. Rather than relying on a single liquidity pool, it searches across available liquidity sources and can split a trade across multiple DEXes, market makers, and different market depths within the same protocol. However, Pathfinder does not necessarily route through every liquidity pool that exists on-chain. A pool must be supported by 1inch and compatible with Pathfinder’s routing and execution logic before it can be considered as part of a swap route.
​
When comparing available liquidity sources, Pathfinder considers factors such as the expected swap rate, available liquidity, price impact, and gas costs. As a result, a supported pool may still not appear in the final route if another pool or combination of liquidity sources offers better execution. This also means that a pool with substantial liquidity or an attractive displayed price may not be used if its protocol, pool type, or execution logic is not currently supported by Pathfinder.

Uniswap v4 allows pools to use hook contracts that execute additional logic at different stages of a pool interaction. This gives developers more flexibility to customize how a pool behaves before or after swaps, liquidity changes, and other operations.

Hooks can introduce features such as dynamic fees, custom pricing logic, access controls, limit-order functionality, MEV protections, or other swap-specific conditions. They may also require additional data to be included with a transaction or change the conditions under which a swap can be executed.
​

Because of this, not every Uniswap v4 pool behaves in the same way. Supporting Uniswap v4 at the protocol level does not necessarily mean that every pool using a custom hook can automatically be routed through Pathfinder. For a hooked pool to be usable, Pathfinder must be able to account for the hook’s behavior when calculating and executing the swap.

Pathfinder must be able to calculate the expected output and execute the swap reliably. An unfamiliar hook may produce a different result from the one calculated by the router or cause the transaction to revert. For example, a hook may adjust fees based on market conditions, require specific hookData, restrict certain trades, or depend on external state such as oracle data. If Pathfinder cannot reliably determine how the hook will affect the transaction, the pool may not be included as a routing source.
​
This is separate from the amount of liquidity in the pool. High liquidity or trading volume does not automatically make a pool compatible with Pathfinder.

For Pathfinder to route through a hooked pool, 1inch needs to be able to determine how the hook affects the swap and construct transactions that interact with it correctly.

This generally requires the hook’s behavior and execution requirements to be sufficiently defined for Pathfinder to account for factors such as pricing, fees, required call data, and any conditions that could affect execution. If a hook introduces custom behavior that is not currently supported, additional integration work may be required before Pathfinder can use liquidity from pools that rely on it.

A Uniswap v4 pool is therefore not automatically routable through 1inch simply because it exists on-chain and contains liquidity. Pathfinder must also support the pool’s execution behavior before it can consider that liquidity when building a swap route.