DAMM v1 Implementation and Limits

This page summarizes the DAMM v1 behavior that is enforced by the on-chain AMM program. Use it when you need exact product limits rather than a high-level explanation.

​

Pool account model

A DAMM v1 pool is a two-token SPL Token pool. The pool account stores: The AMM does not price from raw token account balances alone. It converts the pool’s vault LP holdings back into underlying token amounts, then uses those amounts for swaps, LP minting, withdrawals, and virtual price.

​

Supported curves

DAMM v1 supports two curve families: Constant-product pools do not support imbalanced deposits or single-sided withdrawals in the curve implementation. Stable pools support imbalanced deposits and single-sided withdrawals because those operations are implemented through the stable-swap math.

​

Permissionless constraints

Permissionless pool creation is intentionally constrained: Specialized stable pools, including depeg-aware LST pools, require permissioned pool setup.

​

Fee settings

DAMM v1 fee fractions use a denominator of 100000. The protocol fee is calculated from the total trade fee, not directly from the full input amount. The remaining trade fee stays in the pool and benefits LP token value. For non-zero fee settings, the fee helper returns a minimum fee of one token unit when integer division would otherwise round the fee to zero.

​

Fee tiers and updates

Permissionless fee-tier creation only allows specific trade fee basis points: Customizable permissionless constant-product pools use a different launch-oriented fee path: Pool fees can also be updated after creation. The configured fee-update authority can only decrease the trade fee, cannot change the protocol fee, and cannot reduce below 0.25%. The admin path can set fees and partner fee settings after validating fee fractions and partner limits.

​

Host and partner fees

If a swap includes a host fee account in the expected remaining-account position, the program routes 20% of the protocol fee to that host account and leaves the rest as protocol fee. Partner fees are tracked separately in pool state. When a partner is configured, the partner can accrue up to 50% of protocol-side fees. Partner accounting only applies to protocol fees that remain after host fee routing.

​

Depeg-aware LST support

Depeg mode exists only on stable pools. The program supports: For a depeg pool, token A must be native SOL and token B is the staking or interest-bearing token. The pool multiplies token A balances by 1_000_000 and token B balances by the cached base virtual price before stable-swap calculations. The cached base virtual price is refreshed only when more than 10 minutes have passed since the previous cache update. SPL stake-pool depeg pools store the stake account in pool state and validate the same account on later updates.

​

Activation rules

Some permissionless constant-product pools can be created with an activation point. Activation can be based on either: Before activation, normal swaps are disabled. If a whitelisted vault is configured, that vault can buy during the pre-activation window. Balanced withdrawals are also gated until activation. Mainnet timing limits include:

​

Liquidity operations

The code deliberately rounds some share calculations against the user to account for vault-share precision loss. Integrations should use slippage bounds and quoted amounts rather than assuming exact proportional arithmetic.

​

Liquidity locks

Liquidity locks escrow DAMM v1 LP tokens and increase total_locked_lp on the pool. The underlying assets remain in the AMM and its connected vaults. For constant-product pools, the lock escrow can accrue claimable fee value when virtual price increases. Claiming those fees burns a portion of escrowed LP tokens and withdraws the corresponding underlying token amounts. The claim_fee path rejects non-constant-product pools. Locks restrict control of the LP tokens; they do not remove price risk, vault risk, or smart-contract risk.