Amendment Idea: Concentrated Liquidity AMM

[RomThpt]

Idea: Concentrated Liquidity AMM

Category: Amendment
Status: Idea

This is an early idea for a Concentrated Liquidity Automated Market Maker (CL AMM) for the XRP Ledger. Unlike the existing XLS-30 AMM which distributes liquidity uniformly across all prices, this design would allow liquidity providers to concentrate their capital within specific price ranges, dramatically improving capital efficiency (up to 4000x for stablecoin pairs).

Motivation

The current XRPL AMM (XLS-30) uses a constant product formula where liquidity is distributed uniformly across all prices. This approach is capital inefficient because most liquidity sits idle at price points far from the current market price.

Limitations of XLS-30:

• LPTokens are fungible (all LPs share the same position)
• Fee collection requires withdrawal
• No secondary market for positions
• Capital inefficiency due to uniform liquidity distribution

Benefits of Concentrated Liquidity:

• LPs earn more fees per dollar of capital deployed
• Better prices for traders (lower slippage)
• Positions are unique and tradeable (NFToken-based)
• Fees can be collected without removing liquidity

Key Design Elements

Fee Tiers and Tick Spacing

This idea proposes linked fee tiers that determine both the trading fee and tick granularity. This approach mirrors Uniswap V3's proven model while adapting to XRPL's architecture.

Fee Tier	Trading Fee	Tick Spacing	Tick Base	Best For
STABLE (0)	0.01%	1 bp (0.01%)	1.0001	Stablecoin pairs (USD/EUR)
LOW (1)	0.05%	10 bp (0.1%)	1.001	Correlated assets
MEDIUM (2)	0.30%	60 bp (0.6%)	1.006	Standard pairs (XRP/USD)
HIGH (3)	1.00%	200 bp (2%)	1.02	Exotic/volatile pairs

Why link fee and tick spacing?

1. Capital efficiency: Tighter spreads (lower fees) require finer tick granularity to capture value efficiently
2. Computational optimization: Wider tick spacing means fewer ticks to cross per swap, justifying higher fees
3. Simplicity: Pool creators select one parameter (FeeTier) instead of configuring two
4. Proven model: Directly follows Uniswap V3's successful approach

Tick Range Coverage:

Fee Tier	Ticks for 0.1x - 10x price range
STABLE	~46,000 ticks
LOW	~4,600 ticks
MEDIUM	~770 ticks
HIGH	~232 ticks

Potential Ledger Entries

1. CLAMM

Pool state containing current tick, liquidity, and fee growth.

Field	Type	Description
Asset	Issue	First asset in the pair
Asset2	Issue	Second asset in the pair
FeeTier	UINT8	Fee tier (0-3)
TickSpacing	UINT16	Derived from FeeTier
TradingFee	UINT32	Derived from FeeTier (in 1/1,000,000)
CurrentTick	INT32	Current active tick
SqrtPrice	UINT128	Current sqrt price (18 decimals)
Liquidity	UINT128	Currently active liquidity
FeeGrowthGlobal0	UINT128	Global fee growth for Asset
FeeGrowthGlobal1	UINT128	Global fee growth for Asset2
ProtocolFees0	UINT64	Accumulated protocol fees for Asset
ProtocolFees1	UINT64	Accumulated protocol fees for Asset2

2. CLAMMTick

Per-tick liquidity and fee data. Only ticks with liquidity are stored (sparse).

Field	Type	Description
PoolID	Hash256	Reference to parent CLAMM
TickIndex	INT32	Tick index (must be divisible by TickSpacing)
LiquidityGross	UINT128	Total liquidity referencing this tick
LiquidityNet	INT128	Net liquidity change when crossing
FeeGrowthOutside0	UINT128	Fee growth outside this tick for Asset
FeeGrowthOutside1	UINT128	Fee growth outside this tick for Asset2

3. CLAMMPosition

LP positions linked to NFTokens.

Field	Type	Description
PoolID	Hash256	Reference to parent CLAMM
NFTokenID	Hash256	Associated NFToken
Owner	AccountID	Position owner
LowerTick	INT32	Lower bound of position
UpperTick	INT32	Upper bound of position
Liquidity	UINT128	Liquidity amount
FeeGrowthInside0Last	UINT128	Fee growth snapshot for Asset
FeeGrowthInside1Last	UINT128	Fee growth snapshot for Asset2
TokensOwed0	UINT64	Uncollected fees for Asset
TokensOwed1	UINT64	Uncollected fees for Asset2

Potential Transactions

1. CLAMMCreate

Create a new concentrated liquidity pool.

{
  "TransactionType": "CLAMMCreate",
  "Account": "rCreator...",
  "Asset": { "currency": "USD", "issuer": "rIssuer..." },
  "Asset2": { "currency": "XRP" },
  "FeeTier": 2,
  "InitialPrice": "1500000000000000000"
}

Field	Type	Required	Description
Asset	Issue	Yes	First asset in the pair
Asset2	Issue	Yes	Second asset in the pair
FeeTier	UINT8	Yes	Fee tier (0-3), determines TradingFee and TickSpacing
InitialPrice	String	Yes	Initial sqrt price (18 decimals)

2. CLAMMDeposit

Add liquidity within a price range. Mints an NFToken representing the position.

{
  "TransactionType": "CLAMMDeposit",
  "Account": "rLP...",
  "PoolID": "hash...",
  "LowerTick": -120,
  "UpperTick": 180,
  "Amount": { "currency": "USD", "issuer": "rIssuer...", "value": "1000" },
  "Amount2": { "currency": "XRP", "value": "500" },
  "MinLiquidity": "100000"
}

Field	Type	Required	Description
PoolID	Hash256	Yes	Target pool
LowerTick	INT32	Yes	Lower bound (must be divisible by TickSpacing)
UpperTick	INT32	Yes	Upper bound (must be divisible by TickSpacing)
Amount	Amount	Yes	Maximum Asset to deposit
Amount2	Amount	Yes	Maximum Asset2 to deposit
MinLiquidity	String	No	Minimum liquidity to receive (slippage protection)

3. CLAMMWithdraw

Remove liquidity from a position. Burns the NFToken if fully withdrawn.

{
  "TransactionType": "CLAMMWithdraw",
  "Account": "rLP...",
  "NFTokenID": "hash...",
  "LiquidityAmount": "50000",
  "MinAmount": { "currency": "USD", "issuer": "rIssuer...", "value": "400" },
  "MinAmount2": { "currency": "XRP", "value": "200" }
}

Field	Type	Required	Description
NFTokenID	Hash256	Yes	Position NFToken to withdraw from
LiquidityAmount	String	Yes	Amount of liquidity to remove
MinAmount	Amount	No	Minimum Asset to receive (slippage protection)
MinAmount2	Amount	No	Minimum Asset2 to receive (slippage protection)

4. CLAMMSwap

Execute a swap through the pool.

{
  "TransactionType": "CLAMMSwap",
  "Account": "rTrader...",
  "PoolID": "hash...",
  "AmountIn": { "currency": "USD", "issuer": "rIssuer...", "value": "100" },
  "MinAmountOut": { "currency": "XRP", "value": "45" }
}

Field	Type	Required	Description
PoolID	Hash256	Yes	Target pool
AmountIn	Amount	Yes	Amount to swap in
MinAmountOut	Amount	No	Minimum output (slippage protection)

5. CLAMMCollectFees

Collect accumulated fees without removing liquidity.

{
  "TransactionType": "CLAMMCollectFees",
  "Account": "rLP...",
  "NFTokenID": "hash..."
}

Field	Type	Required	Description
NFTokenID	Hash256	Yes	Position NFToken to collect fees from

6. CLAMMVote

Vote on protocol fee percentage (similar to XLS-30).

{
  "TransactionType": "CLAMMVote",
  "Account": "rLP...",
  "PoolID": "hash...",
  "ProtocolFee": 1000
}

Field	Type	Required	Description
PoolID	Hash256	Yes	Target pool
ProtocolFee	UINT32	Yes	Proposed protocol fee (in 1/1,000,000)

Potential RPCs

clamm_info

Get pool information.

Request:

{
  "command": "clamm_info",
  "pool_id": "hash..."
}

Response:

{
  "pool": {
    "asset": { "currency": "USD", "issuer": "rIssuer..." },
    "asset2": { "currency": "XRP" },
    "fee_tier": 2,
    "current_tick": 50,
    "sqrt_price": "1050000000000000000",
    "liquidity": "1000000000",
    "trading_fee": 3000,
    "protocol_fee": 0
  }
}

clamm_positions

Query positions for an account.

Request:

{
  "command": "clamm_positions",
  "account": "rLP..."
}

Math Precision

All implementations would need to use:

• u128 minimum for liquidity and sqrt price calculations
• 18 decimal places for price representation
• Signed i128 for liquidity delta when crossing ticks

Price Calculation:

SqrtPrice(tick) = TICK_BASE^(tick/2) * 10^18

Where TICK_BASE depends on the fee tier:

Fee Tier	TICK_BASE
STABLE	1.0001
LOW	1.001
MEDIUM	1.006
HIGH	1.02

Swap Algorithm

1. Determine swap direction (Asset -> Asset2 or Asset2 -> Asset)
2. While amountRemaining > 0:
   a. Calculate maximum swap amount at current tick
   b. If amountRemaining <= maxAtTick: swap within tick, done
   c. Else: consume liquidity at tick, cross to next tick
   d. Update Liquidity += LiquidityNet of new tick
3. Update pool state (CurrentTick, SqrtPrice, fee accumulators)
4. Transfer tokens

Feedback Requested

1. Is the linked fee tier / tick spacing approach appropriate, or should they be independently configurable?
2. Should multiple pools with different fee tiers be allowed for the same asset pair?
3. Should there be a minimum liquidity requirement per tick to prevent dust positions?
4. Should there be an auction mechanism similar to XLS-30?
5. How should protocol fees be distributed?
6. Should positions be transferable via NFToken transfer, or require a dedicated mechanism?
7. Are there any XRPL-specific considerations that would make this design impractical?

Looking forward to community feedback!

References

• Uniswap V3 Whitepaper
• Uniswap V3 Core Contracts
• XLS-30 AMM Specification

[mvadari]

Hi @RomThpt - please review the guidelines for how to create discussions in this repo. There should not be a number assigned (those are now assigned at PR) and there should be a preamble section labeling this as an Idea (since it is not fleshed out enough to be a Proposal).

[RomThpt]

done

[RomThpt]

[mvadari]

@RomThpt please update the original discussion instead of posting separately. The edit history will show the diff.

[ajkagy]

do you have any more proposed specs for "NFToken-based LP positions that are fully tradeable"? Would be curious how you see that working for the XRPL.

[RomThpt]

so with XLS-30 everyone gets the same LP token because all LPs share the full price range. but with concentrated liquidity you pick your own range, every position is unique. NFTokens make sense here the flow:

1. deposit with your price range
2. get an NFToken for that position
3. want out? sell the NFT on any marketplace
4. buyer gets the liquidity + accrued fees

on-ledger its basically:

NFToken (yours)
    |
    +---> CLAMMPosition
              - pool id
              - your tick range  
              - liquidity amount
              - fees earned

own the NFToken = control the position the nice part is we reuse existing XRPL NFToken infra instead of building something new