How to read this
Fee rate is what the position earns while price is inside the band. It scales with concentration, which is exact arithmetic: a ±5% range packs about twice the liquidity per dollar of a ±10% one, so it earns about twice the rate.
Days in range is the other half, and the half most people skip. For a price that moves like a random walk, the expected time before it first leaves a band of width w is ln(1+w)² / σ². At SOL's typical 4% daily volatility a ±5% band lasts about a day and a half. A ±2% band lasts about six hours.
What this deliberately does not include
There is no "net yield" column here, and that is on purpose. Turning this into one number requires modelling impermanent loss over the price path, and IL is an opportunity cost against holding — not a fee you can multiply by a rebalance count. We tried exactly that and it produced nonsense, so we took it out rather than ship a confident-looking wrong answer.
For the divergence side, use the impermanent loss calculator, which computes it exactly for a given price move.
Picking a volatility number
The presets are rough long-run figures: SOL around 4% a day, ETH 2.5%, BTC 2%, stable pairs near 0.1%. If you want precision, take the standard deviation of daily log returns over the last 30 days and use that. In a quiet market ranges last far longer than the table suggests; in a violent one, far less.
From percent to ticks
Orca Whirlpools and Raydium CLMM do not store a range in percent. They store two ticks, and each tick is a 0.01% step in price (price = 1.0001tick). Because the steps multiply, a range that is symmetric in percent is not symmetric in ticks. Counted from the pool's current tick:
upper offset = ln(1 + w) / ln(1.0001)
lower offset = ln(1 − w) / ln(1.0001)| Range | Upper bound | Lower bound | Snapped to spacing 4 |
|---|---|---|---|
| ±5% | +488 ticks | −513 ticks | +488 / −512 |
| ±10% | +953 ticks | −1,054 ticks | +952 / −1,052 |
Both bounds also have to land on a multiple of the pool's tick spacing — 4 on Orca's SOL/USDC 0.04% pool — so the interface snaps them to the nearest allowed tick. That moves each edge by a few hundredths of a percent at most.
A practical default
- Running it by hand: ±15–20% on SOL. Two or three rebuilds a month is something a person can actually keep up with.
- Running a bot: ±5–10% becomes reasonable, because the rebuild happens without waiting for you. Ours runs a wide/narrow pair from base widths of ±15% and ±8%, scaled by volatility and clamped to 12–30% (wide) and 7–15% (narrow) — which is why automated rebalancing matters more than the exact width.
- Two positions: a wide one that almost never leaves range and a narrow one that captures the bulk of the fees. It hedges the width decision instead of betting on it.