Pre-Release Documentation

This describes a pre-release version of LBAMM. Interfaces and behavior may change.

Verify the exact repository commit before building production integrations.

Mixing Pool Types in Routes

LBAMM routes can be multi-hop: a single swap can pass through multiple pools, and those pools may be different pool types.

This page is for routers and aggregators building multi-hop routes across LBAMM pools.

Core idea

A multi-hop route is a sequence of independent pool executions:

Each hop executes according to that pool type’s swap mechanics
The route as a whole is one LBAMM execution, but pool math does not “blend” across hops

If you mix pool types in a route, the only thing that “connects” them is the output amount from hop i becoming the input amount to hop i+1.

When routes mix pool types, integrators must treat each hop as having its own mechanics, including:

How price is determined (e.g., state-driven vs hook-supplied)
How liquidity is represented and consumed (e.g., reserves vs active liquidity over ranges)
Whether partial fills are possible and under what conditions
What extra per-hop parameters are required (e.g., price limits in extra data)
How quoting should be performed for that pool type (what must be simulated vs what can be assumed)

There is no universal quoting shortcut. A valid route quote must respect the mechanics of every hop.

Across all pool types, the route is still “just hops”:

A hop specifies a poolId, tokenIn, tokenOut, and an amount (input-based or output-based depending on the swap path).
The result of a hop is an amount of tokenOut that becomes the next hop’s tokenIn.

Imagine you want to swap TOKEN_A → TOKEN_D using a 3-hop route:

Conceptually:

Hop 1 produces TOKEN_B according to the Dynamic Price Pool’s price movement and liquidity-range mechanics.
Hop 2 consumes that exact TOKEN_B output and produces TOKEN_C using the Fixed Price Pool’s fixed execution price and reserve constraints.
Hop 3 consumes that TOKEN_C output and produces TOKEN_D using the Single Provider Pool’s hook-supplied execution price and core reserve availability.

Even though the route is one operation, each hop must be quoted and simulated under the correct assumptions for that pool type.

Treat each hop as a separate pricing engine.
Build quoting logic that can evaluate each pool type’s swap semantics.
When constructing multi-hop routes, ensure the per-hop inputs you supply (amounts, limits, extra data) are valid for that pool type.

That’s the whole model: multi-hop routing is composition of per-hop mechanics, not a new liquidity model.