Concentrated Liquidity on Solana: What Actually Changes

Concentrated liquidity transformed automated market making by letting providers focus their capital in the price ranges where trading actually happens, achieving order-book-class depth with a fraction of the total value locked. The design is well understood on Ethereum. Bringing it to Solana, though, is not a matter of translating Solidity to Rust. Solana's execution model is different enough that several core decisions have to be reconsidered from scratch.

The account model reshapes your state

On the EVM, a contract owns a single sprawling storage space and reads it freely. On Solana, state lives in accounts that must be declared up front for every transaction, and there is a hard limit on how many a single transaction can reference. A concentrated-liquidity pool has potentially thousands of initialised ticks, each describing the liquidity at a price boundary. You cannot put them all in one account, and you cannot reference all of them in one swap. So the very first design question is how to shard tick state across accounts such that a typical swap touches only the few it actually crosses.

The compute budget is a hard wall

Every Solana transaction runs under a compute-unit budget. A swap that crosses many tick boundaries does meaningful arithmetic at each one, and a large swap through a fragmented book can simply run out of budget and fail. This is not a performance nicety you optimise later; it is a correctness constraint you design around. We cap the number of ticks any single instruction will cross and expose a multi-hop path so that large swaps are stitched together off-chain into several instructions, each within budget. The router has to understand this limit as a first-class constraint, not discover it at runtime.

Tick discovery wants a bitmap

When a swap consumes the liquidity at the current price, it needs to find the next initialised tick efficiently. Scanning the entire price space is hopeless. We maintain a bitmap of initialised ticks so the next active boundary is found with a bit-scan rather than a search, and we keep that bitmap in a layout that is cheap to read within the compute budget. This single structure is what makes large, multi-tick swaps feasible at all.

Routing is where the user experience lives

Because Solana account limits constrain how much a single transaction can do, the off-chain router carries more responsibility than on the EVM. It maintains a live graph of pools and depth, splits an order across pools and tick ranges to minimise price impact, and packs the result into versioned transactions using address-lookup tables to fit more accounts than a legacy transaction allows. Done well, a six-figure swap can settle with single-digit basis points of impact and finalise in well under a second.

Test the math like your TVL depends on it

Tick math is unforgiving. Rounding that drifts by a single unit per swap compounds into real value over millions of trades, and an off-by-one in liquidity accounting can let value leak from the pool. We fuzz the swap-and-mint paths with randomised sequences and assert invariants on reserves and fee accrual, and we have the core arithmetic independently reviewed before it ever holds mainnet liquidity.

The reward for this work is a venue that quotes competitive prices on its core pairs against centralised exchanges while costing a fraction of a cent per swap. But getting there means respecting Solana for what it is rather than treating it as an EVM with a different syntax.