Liquidity producer
The core role. Provides assets to the pool and makes liquidity available to consumers.
A producer deposits assets into a pool and receives shares — fungible ERC6909 claims on a fixed fraction of the pool. Withdrawal is the inverse: shares are burned and redeem the same fraction of every reserve.
addLiquidity(poolId, tokens[], maxAmounts[], minLpShares, recipient, deadline) // proportional mint
removeLiquidity(poolId, tokens[], lpShares, minAmounts[], recipient, deadline) // proportional burn
zapIn(poolId, assetIdx, lpSharesOut, maxAmountIn, recipient, deadline) // single-asset entry (star only)
zapOut(poolId, assetIdx, lpSharesIn, minAmountOut, recipient, deadline) // single-asset exit (star only)On star pools a producer can enter and exit with a single asset (zap); on delta pools, single-asset entry is composed as a swap followed by a proportional add — the pairwise pricing model keeps its primitives pairwise.
The production workflow
The workflow is the simplest in the AMM landscape, and it is inherited from the axioms of the primitive, not bolted on:
- Always in range. The liquidity is dynamic — it follows the state price by construction. There is nothing to monitor, reposition, or rebalance, and no gas spent doing so.
- Fees are capitalized. Trading fees are added directly to the reserves, so they accrue to the position and count towards the liquidity itself. No harvesting, no claiming, no separate fee balance.
- Fungible position. A share is a share. Positions compose: they transfer like tokens, wrap to ERC20 where integrations need it, and serve directly as collateral for leverage.
What the producer earns and risks
Producers earn the pool's swap fees and, on the stabilizing side of flow, the slippage that consumers pay. The position's composition drifts with the market (the pool's reserves rebalance against flow) — the classical exposure of liquidity provision, bounded here by the domain: the pool cannot be pushed beyond the admissible liquidity ratio in a single transaction.