This describes a pre-release version of LBAMM. Interfaces and behavior may change.
Verify the exact repository commit before building production integrations.
Liquidity Positions
This page defines what a position is in LBAMM, how positions are identified, and what guarantees exist at the protocol level.
Crucially, this page describes the abstract position model shared across all pool types. The concrete meaning of a position—ranges, pricing, ownership semantics, or accounting—is defined entirely by the pool type.
What is a position?
A position represents a share of a pool’s liquidity reserves and accrued fees.
- Every position is associated with exactly one pool
- A position’s economic meaning is defined by the pool type’s liquidity model
- The LBAMM core does not understand how positions are represented within a pool type
From the core AMM’s perspective, a position is simply an identifier that a pool type uses to attribute liquidity changes and fee collection.
Important: Positions are not a protocol-level primitive with universal semantics. They are defined and interpreted by pool implementations.
Position identity
Base position identifier
When liquidity is added, removed, or fees are collected, the core AMM derives a base position identifier deterministically.
The base position ID is computed from:
- The liquidity provider address
- The liquidity hook address
- The target
poolId
bytes32 basePositionId = keccak256(
abi.encode(
provider,
liquidityHook,
poolId
)
);
Because the poolId is included, base position identifiers:
- Are unique per pool
- Cannot be reused across different pools
Pool-type position identifiers
Pool types may use the base position ID directly, or derive a final position ID by combining it with pool-type-specific parameters.
For example, a pool type may:
- Use the base position ID as-is
- Hash the base ID together with encoded position parameters
The only protocol-level expectation is that a pool type uses a stable and deterministic method to resolve the same position across:
- Liquidity additions
- Liquidity removals
- Fee collection
Position lifecycle
At the core AMM level, positions do not have an explicit lifecycle beyond liquidity modification.
The core exposes three position-related actions:
- Add liquidity
- Remove liquidity
- Collect fees
Whether these actions:
- Create a new position
- Modify an existing position
- Represent directional changes on the same position
is entirely up to the pool type’s model.
What the core AMM does not know
The core AMM does not understand or enforce:
- Position ranges or parameters
- Position ownership or transferability rules
- How liquidity is split across positions
- How fees are allocated between positions
- Whether positions are enumerable or transferable
Any such behavior must be implemented by the pool type or enforced via hooks.
Hooks and positions
During liquidity operations, hooks may observe position-related context.
Specifically, position hooks receive a LiquidityContext that includes:
- The liquidity provider address
- The pool’s token pair
- The resolved position identifier
This allows hooks to:
- Validate whether a provider may modify a position
- Enforce custom permissioning or constraints
All position-level authorization is expected to be enforced via hooks. The core AMM does not impose position permissions.
Fees and positions
LP fees are attributed to positions by the pool type.
- The core AMM tracks only pool-level fee balances
- Pool types determine how fees accrue to individual positions
The core never allocates fees directly to positions.
Common misconceptions
The following statements are false in LBAMM:
- “Positions are first-class objects in LBAMM”
- “Positions are portable across pool types”
- “Positions are NFTs”
Positions exist only within the context of a specific pool type’s implementation.
Why this matters
By keeping positions pool-defined rather than protocol-defined, LBAMM enables:
- Diverse liquidity models without shared constraints
- Clear trust boundaries between core and pool logic
- Explicit, hook-driven permissioning
Subsequent sections describe how individual pool types implement and interpret positions in detail.