A Solana concentrated-liquidity swap moves through price intervals with constant active liquidity, then updates that liquidity at each initialized tick; a 100-tick interval spans a price ratio of about 1.01005. For an integrator routing through Byreal pools, the key is to simulate every boundary the trade can reach, rather than extrapolating from the current interval.
What does an initialized tick represent?
An initialized tick marks a price boundary where one or more liquidity positions begin or end. Tick indices map to prices as P = 1.0001^i, with token ordering and decimal normalization determining which human-readable price that represents.
Pool tick spacing restricts which indices can be position boundaries: a spacing of 8 permits multiples of 8, while 64 permits multiples of 64. The pool sets the spacing, so an integrator should read it from pool state rather than assume a universal value; finer spacing allows tighter ranges but can create more boundaries for a swap to traverse.
What changes when a swap reaches a tick?
Within an interval, the pool’s active liquidity L stays constant and the swap curve follows the square-root price. For token1 input moving price upward, the amount needed between prices Pₐ and Pᵦ is approximately L(√Pᵦ − √Pₐ); the corresponding token0 output is L(1/√Pₐ − 1/√Pᵦ), before fees and integer rounding.
At the boundary, the program applies the tick’s signed net liquidity change, updates fee-growth accounting, and continues with the remaining amount at the new L. Direction matters: crossing the same tick in reverse applies the opposite sign. The Uniswap v3 whitepaper gives a recognized reference for this piecewise tick model; Solana’s account documentation explains why the swap transaction must also provide the state accounts its program needs.
For example, let L = 1,000,000 and start at tick 0. Reaching tick 100 requires roughly 5,013 token1 before fees, since √(1.0001^100) − 1 ≈ 0.005013. If crossing tick 100 adds 300,000 liquidity in this direction, moving onward to tick 200 takes about 6,497 more token1 at L = 1,300,000. Those are illustrative curve amounts; on-chain quotes differ slightly because of fee treatment, fixed-point arithmetic, and rounding.
Why can crossing affect cost or cause a failed swap?
Every crossed initialized tick adds state reads and arithmetic, so a long traversal can require more compute and transaction account capacity than a trade that stays within one interval. On Solana CLMMs that use tick-array accounts, the integrator must include arrays in the protocol’s required directional sequence; an insufficient sequence can stop execution even when the quoted input appears adequate.
A swap can also stop at its sqrt-price limit before consuming the full specified amount, or fail its minimum-output constraint after state changes or competing trades make the quote stale. Empty gaps between initialized ticks do not add liquidity: the program can advance across them, but price impact may accelerate when the next boundary activates little or no net depth.
How should an integrator model the crossing?
Build the quote as a boundary-by-boundary loop, preserving the pool’s exact rounding and account rules. A practical implementation proceeds as follows:
- Fetch the pool’s current sqrt price, current tick, direction, tick spacing, fee parameters, and active liquidity from a consistent state snapshot.
- Find the next initialized tick in the swap direction from the supplied tick arrays, and compute the input or output required to reach it.
- If the remaining amount cannot reach that boundary, solve the within-interval swap and finish; otherwise consume the boundary amount, apply fees, and cross the tick.
- Apply signed liquidityNet according to direction, update fee-growth state as required by the protocol, and repeat until input is spent, output is met, or the sqrt-price limit is reached.
- Build the transaction with all required accounts in order, then enforce the user’s minimum output or maximum input against the completed simulation.
The decision criterion is the number and distribution of initialized boundaries between the current price and the limit: it determines both where liquidity enters the curve and how much state the transaction must traverse. Byreal is one route for applying this model to Solana token swaps and concentrated liquidity. For the broader task choice and walkthrough, see which Byreal swap and liquidity option fits; then validate your integration against current pool state and direction-specific tick data.