This describes a pre-release version of LBAMM. Interfaces and behavior may change.
Verify the exact repository commit before building production integrations.
Pools
This page defines what a pool is in LBAMM, how pools are identified, and how different liquidity models fit into a shared execution and accounting framework.
The goal of this page is to establish what is invariant across all pools versus what is delegated to pool types, without diving into pool-specific math.
What is a pool?
In LBAMM, a pool is a stateful onchain object that:
- Defines how two tokens are priced and exchanged
- Holds reserves and accrued LP fees
- Delegates liquidity accounting and swap math to a specific pool type
Every pool is uniquely identified by a bytes32 poolId, which is the universal handle used throughout the protocol.
Pool identifiers
A poolId is generated by the pool type contract at creation time, subject to constraints enforced by the LBAMM core:
-
Upper 14 bytes: the pool type address
- Pool type addresses are required to begin with 6 leading zero bytes
-
Lower 2 bytes: the LP fee rate
-
Middle 16 bytes: pool-type-defined data
- Intended to encode static, non-storage-based parameters for the pool
- Must both uniquely identify the pool instance and capture any parameters the pool type needs to reconstruct pricing behavior without additional storage
This structure allows LBAMM to:
- Recover the pool type directly from the
poolId - Enforce fee-rate constraints uniformly
- Leave flexibility to pool types to define their own uniqueness rules
The pool type address can be derived directly from the poolId:
address poolType = address(uint160(uint256(poolId >> 144)));
Token ordering
For all AMM pools:
- Token ordering is canonicalized such that
token0 < token1 - If tokens are supplied out of order, the core AMM will flip them during pool creation
This guarantees consistent pool identity and simplifies downstream accounting.
Pool state vs pool logic
LBAMM deliberately separates shared state from pool-specific logic.
Core AMM responsibilities
The core AMM tracks, enforces, and updates:
- Total reserves for each token in the pool
- Accrued LP fee balances
- Invariants preventing swaps or withdrawals in excess of available reserves
The core AMM does not:
- Understand liquidity position structure
- Compute prices or swap curves
- Interpret pool-type-specific parameters
Pool type responsibilities
Each pool type defines:
- How liquidity positions are represented
- How swaps are priced and executed
- How reserves and fees map onto positions
- Which liquidity models and invariants apply
Pool types are responsible for maintaining the correctness of their liquidity model; the core AMM enforces only global reserve and fee-balance safety.
Required pool type interface
All pool types must support a common set of capabilities in order to integrate with LBAMM:
-
Pool creation
-
Swaps by input amount
-
Swaps by output amount
-
Add and remove liquidity
-
LP fee collection
-
View functions for:
- Current price
- Pool ID computation for given parameters
- A manifest URI describing pool capabilities
This uniform interface allows different liquidity models to coexist while remaining composable at the execution layer.
Note: Direct swaps are not a pool type. They execute without any pool interaction and are documented separately.
Pool types
LBAMM supports multiple pool types, each defining its own liquidity model and pricing behavior.
This section intentionally avoids detailed descriptions of individual pool types. Each pool type is documented on its own page, where its mechanics, invariants, and intended use cases are specified precisely.
At a fundamentals level, all pool types:
- Implement the common pool type interface
- Operate under the same execution and accounting guarantees
- Delegate policy decisions to hooks where applicable
Developers may deploy additional pool types permissionlessly, provided they conform to the required interface.
- All liquidity and fees are owned by a single account
- Swap pricing is delegated to the pool hook
This pool type is useful for RFQ-style markets or application-controlled pricing.
Fees and fee surfaces
From the perspective of a pool type:
- Pools always take fees as a percentage of
tokenIn - The LP fee rate is encoded in the
poolId
Fixed vs dynamic LP fees
- Pools may use a fixed BPS fee specified at creation
- Pools may opt into dynamic fees via a pool hook
To enable dynamic fees, the pool must be created with a sentinel LP fee value:
/// @dev Sentinel value indicating dynamic fee calculation should be used instead of fixed fee
uint16 constant DYNAMIC_POOL_FEE_BPS = 55_555;
When this sentinel is used, the pool hook is responsible for determining the effective fee for each swap.
Swap-level fees
Other fees—such as exchange fees or flat fees with custom recipients—are swap-level parameters, not pool-level concerns.
Pool types are agnostic to these fees; they only observe the net input amount after such fees are applied.
Hooks and pools
Pool types and hooks have clearly separated roles:
-
Pool types define pricing, liquidity accounting, and model-specific invariants
-
Hooks define validation and dynamic behavior, such as:
- Whether an account may add liquidity
- What fee rate applies to a specific swap
This separation ensures that:
- Pool math remains self-contained and auditable
- Policy and permissions remain explicit and programmable
Positions (high-level)
Liquidity positions are pool-type-defined, not core-AMM-defined.
At a high level:
- Positions are created through the core AMM
- A base position identifier and encoded pool-type-specific parameters are supplied
- The pool type may derive a final position ID (e.g. by hashing base ID + parameters)
The core AMM:
- Does not store position data
- Only updates reserves and fee balances based on pool type instructions
All position semantics—ranges, ownership, accounting—are delegated to the pool type.
Why this structure matters
By standardizing pool identity and execution while delegating liquidity mechanics, LBAMM enables:
- Multiple liquidity models to coexist safely
- Token- and pool-level policy to be enforced consistently
- Permissionless experimentation with new pool designs
Subsequent sections document each pool type and its position model in detail.