Unlocking Advanced DeFi: Understanding and Building CLMMs on Solana

The world of decentralized finance (DeFi) is constantly evolving, with concentrated liquidity market makers (CLMMs) standing out as a significant innovation. Inspired by Uniswap V3, CLMMs offer enhanced capital efficiency compared to traditional constant-product AMMs. This article will guide you through the fundamental principles and the architectural blueprint for constructing a simplified CLMM program on the Solana blockchain.

We’ll delve into the core mathematical models and explore the critical components of the program’s state and instructions. While this exploration focuses on a foundational implementation using the Steel framework in Rust, it lays the groundwork for understanding more complex, production-grade systems.

The Mathematical Engine: Core Formulas of Concentrated Liquidity

At the heart of any CLMM are precise mathematical formulas that govern pricing, liquidity, and token amounts. These calculations often involve fixed-point arithmetic for precision.

1. Tick Index to Square Root Price Conversion

CLMMs utilize discrete “ticks” to define price ranges. Converting between a tick index and its corresponding square root price is crucial for managing liquidity across these ranges. This conversion uses a logarithmic spacing, ensuring efficient representation of price dynamics. All sqrt_price values are typically represented in a Q64.64 fixed-point format, offering high precision for calculations without resorting to native floating-point numbers which are generally avoided in smart contracts for determinism and security.

For example, a sqrt_price in a SOL/USDC pool might translate to a specific price per SOL, accounting for token decimal differences.

2. Calculating Token Amounts (Delta A & Delta B)

To provide or remove liquidity within a specific price range, the CLMM needs to determine the exact amounts of Token A (Delta A) and Token B (Delta B) required. These calculations depend on the amount of liquidity being provided and the lower and upper square root price bounds of the position. Conversely, the system can also calculate the next price given a desired input amount of a token.

Architecting the Solana CLMM Program: Key State Accounts

Our Solana CLMM program relies on specific account structures to manage its state:

1. The `Pool` Account

The Pool account acts as the central hub for the liquidity pool. It stores global parameters and aggregated data:

• `tick_spacing`: Defines the granular separation between ticks.
• `fee_rate` & `protocol_fee_rate`: Determine the trading fees and protocol-specific fees.
• `liquidity`: The total active liquidity currently available in the pool.
• `sqrt_price`: The current square root price of the pool (in Q64.64 format).
• `tick_current_index`: The current tick the pool’s price resides in.
• `token_mint_a` & `token_mint_b`: Public keys for the two tokens in the pool.
• `token_vault_a` & `token_vault_b`: SPL token accounts holding the actual tokens.
• `fee_growth_global_a` & `fee_growth_global_b`: Accumulators for fees earned globally, per unit of liquidity.
• `protocol_fee_owed_a` & `protocol_fee_owed_b`: Unclaimed protocol fees.
• `ticks`: An array representing the state of various price ticks within the pool.

2. The `Tick` Struct

Each Tick struct within the Pool‘s array records vital information about a specific price point:

• `initialized`: Indicates if the tick has been activated by a liquidity position.
• `liquidity_net`: The *net* change in liquidity when crossing this tick. It’s signed because liquidity is *added* when crossing a lower tick upwards and *removed* when crossing an upper tick upwards. This allows efficient tracking of active liquidity as the price moves.
• `liquidity_gross`: The total liquidity contained within this tick’s boundaries.
• `fee_growth_outside_a` & `fee_growth_outside_b`: Fee growth accumulated when the pool’s current price is *outside* this tick’s range.

3. The `Position` Struct

Individual liquidity providers (LPs) manage their specific liquidity ranges through a Position account:

• `liquidity`: The amount of liquidity provided by this position.
• `tick_lower_index` & `tick_upper_index`: The specific price range (defined by ticks) for this position.
• `fee_growth_checkpoint_a` & `fee_growth_checkpoint_b`: Snapshots of fee growth at the time of the last liquidity adjustment, used to calculate earned fees.
• `fee_owed_a` & `fee_owed_b`: Accumulating fees yet to be claimed by the LP.

Core Program Instructions: How the CLMM Operates

The CLMM facilitates several key actions:

1. `InitializePool`

This instruction sets up a new liquidity pool, defining its parameters like tick_spacing and fee_rate. It also creates the necessary SPL token vault accounts to hold Token A and Token B. Initially, the pool has no liquidity, and all ticks are uninitialized.

2. `InitializePosition`

Before adding liquidity, an LP must initialize a Position account. This instruction defines the lower and upper tick indices for the LP’s desired liquidity range. Crucially, it validates that these ticks are within acceptable bounds and adhere to the pool’s tick_spacing rules.

3. `IncreaseLiquidity`

This is where LPs deposit tokens to provide liquidity. The instruction calculates the precise amounts of Token A and/or Token B an LP must deposit based on their desired liquidity amount and the current pool price relative to their chosen tick range:

• If the current price is *above* the LP’s range, only Token A is deposited.
• If the current price is *within* the LP’s range, both Token A and Token B are deposited.
• If the current price is *below* the LP’s range, only Token B is deposited.

The instruction then updates the pool’s active liquidity (if the position is currently in range), adjusts the state of the relevant lower and upper ticks, and accrues fees for the LP based on the fee_growth_inside their position’s range. This fee calculation uses checkpoints to determine fees earned since the last update, ensuring LPs receive their proportional share.

4. `Swap`: The Trading Engine

The Swap instruction is the core of the trading functionality. It processes a user’s trade by iteratively consuming the input amount until the trade is complete. The swap loop handles two primary scenarios:

• **Sufficient Liquidity**: If the current tick segment has enough liquidity to cover the remaining input, the price is updated, fees are calculated, and the swap concludes.
• **Liquidity Exhausted**: If the current segment’s liquidity is insufficient, the system consumes all available liquidity in that segment, *crosses the next initialized tick*, updates the pool’s `liquidity` and `tick_current_index`, updates the `fee_growth_outside` for the crossed tick, and continues the swap in the new segment.

This process continues until the entire input amount is consumed, updating the pool’s sqrt_price, tick_current_index, and fee_growth_global accumulators accordingly. Fees are accumulated per unit of liquidity based on the input token, and protocol fees are also collected.

Critical Considerations for Production CLMMs

While this article outlines a functional CLMM, it’s crucial to understand significant differences between an educational implementation and a production-ready system:

1. Integer Arithmetic is Paramount: For clarity, `f64` (floating-point numbers) was used in the example code. **However, using floating-point math in production smart contracts is a critical security and precision risk.** Production CLMMs **must** use integer arithmetic with carefully managed fixed-point representations and checked operations to prevent precision loss, rounding errors, and potential exploits.
2. Scalable Tick Management: Solana accounts have size limits. The simple `[Tick; MAX_TICKS]` array used here is not scalable for a real-world CLMM. Production-grade systems, like Orca Whirlpools, employ sophisticated data structures such as **tick array accounts** to store tick data efficiently and allow for dynamic scaling without hitting account size limitations.

Conclusion

Building a Concentrated Liquidity Market Maker on Solana is a complex yet rewarding endeavor. This deep dive has explored the core mathematics, state management through Pool, Tick, and Position accounts, and the essential instructions for initializing pools and positions, providing liquidity, and executing swaps. While foundational, this understanding is vital for anyone looking to innovate in the decentralized exchange space. We encourage you to explore the full source code and consider implementing missing functionalities like DecreaseLiquidity, CollectFees, and ClosePosition to further solidify your understanding.