Skip to content
Unimod

Liquidity consumer (swapper)

Consumes liquidity from the pool by swapping assets.

A consumer exchanges one asset of a pool for another. Two entry points cover both directions of intent, through the Router:

swapExactIn(poolId, tokenIn, tokenOut, assetInIdx, assetOutIdx, amountIn,  minAmountOut, recipient, deadline)
swapExactOut(poolId, tokenIn, tokenOut, assetInIdx, assetOutIdx, amountOut, maxAmountIn, recipient, deadline)

Every trade is protected twice: by the caller's slippage bound (minAmountOut / maxAmountIn) and by a deadline. Quotes are read off-chain through the Lens (previewSwapIn / previewSwapOut) — no simulation infrastructure needed.

What the consumer pays

The price paid decomposes cleanly:

  • The state price moves according to the constant-liquidity model: the volume of the trade and the liquidity it meets determine the log-price increment — nothing else enters.
  • The executed price averages the fill: it realizes 2/32/3 of the total state-price move.
  • The fee is a single, low fixed fee per pool, added directly to the reserves.

There is one pool per asset set — no fee-tier fragmentation, no choosing among duplicated pools. The total cost of a trade (slippage + fee) is visible up front, and the post-trade domain check guarantees the pool cannot be pushed into an arbitrageable configuration by the trade.

Why the liquidity is good to consume

Two properties of the primitive work directly for the consumer. The liquidity is concentrated around the current state price, so quoted depth is where trading actually happens. And on star pools routing is trivial: every pair prices through the hub, consistently, with no internal arbitrage taxing the flow.