Solidly
Solidly liquidity pools let V3 providers concentrate capital within chosen price ranges
Solidly liquidity pools support token swaps, while V3 lets liquidity providers concentrate their capital between chosen price bounds and earn from activity within that range. A position stops earning when the market price leaves its range. Choosing a pool therefore involves trading demand, reward incentives and the cost of maintaining the position.
· updatedThe pool's chain and version identify its liquidity rules. Within V3, the chosen range also affects how much attention and transaction spending a position may need as market prices move.
The short version: Rebalancing a V3 position requires separate wallet confirmations, with costs shaped by gas, existing allowances and any necessary token swap.
Price bounds control when V3 capital participates
Two bounds define a V3 position's active price range. Liquidity providers choose those bounds, and traders use the liquidity available around the execution price. Concentration puts more capital to work within selected prices than spreading the same deposit across the full curve.
Width changes the trade-off. A narrow band can increase earning efficiency while the price remains inside it. The price also has less distance to travel before leaving those bounds. A wider band covers more prices with less concentration. Neither choice supplies a fixed return, because trading activity and competing liquidity affect earnings.
Range settings determine the actual exposure
Width and tick spacing
Ticks mark permitted price boundaries. The rebalance editor snaps bounds to the pool's tick spacing. Its initial proposal preserves the old range's width in ticks and centres that range around the current price. Providers can adjust the proposed bounds before proceeding.
Price units
The quote direction identifies which token supplies the price unit. Flipping that direction changes how the bounds read. The editor also supports entering bounds as prices or ticks, so those units need to match the intended range.
Trading activity and incentives pay different rewards
V3 allocates 80% of pool swap fees, 100% of pool SOLID emissions and 100% of direct LP bribes to liquidity providers collectively. An individual position earns its applicable share; those allocations are not percentages of the provider's deposited balance. Trading fees require swaps, while emissions depend on the incentives that veSOLID voting directs toward the pool. Other protocols can fund direct LP incentives or offer voter bribes to attract voting support. LP bribes reward liquidity, while voter bribes reward voting. Customized incentives can also target particular concentrated-liquidity ranges.
A pool's incentive budget and a position's eligibility matter alongside range width. Higher concentration changes how capital participates, while trading demand, competing liquidity and incentive allocations determine the income available.
V3 computes position rewards off-chain and verifies claims through its on-chain rewards distributor. Accrued rewards can await synchronization and the security buffer on the chain that earned them. An active range therefore need not produce an immediately claimable balance.
Pool identity stays specific to its chain and version
Each chain has its own pool contracts and rewards, so identical token symbols do not identify the same deployment. The selected network and contract version establish which position and reward rules apply. Original Fantom V1 pool-share tokens and gauge deposits differ from V3 range positions and distributor-based rewards. Their reward arrangements belong to different implementations, even when both carry the Solidly name.
Rebalancing replaces a range through separate transactions
A rebalance withdraws the old position, adjusts the token ratio through a swap where necessary and deposits into a new range. Access remains wallet-dependent during the feature's gradual rollout. A wallet without access receives an unavailable message instead of a plan.
The plan allocates withdrawn tokens
The dialog identifies the withdrawal amounts, proposed deposit and tokens that would remain in the wallet. Where a swap is necessary and supported, it requests quotes from enabled aggregators on that chain. The selected quote includes expected output, minimum output and price impact.
Aggregator coverage varies by chain. Without coverage, the rebalance supports withdrawal and deposit without an integrated swap. A provider who needs a different token ratio must arrange that swap separately. The two-step path can otherwise leave a single-sided allocation.
The wallet owner confirms each required operation
A V3 rebalance consists of separate transactions that the wallet owner confirms individually. The sequence runs from withdrawal through any required swap approval and swap, then pool approvals and deposit. Existing allowances and an unnecessary swap can remove transactions from that sequence. Gas therefore depends on the selected chain and operations that remain necessary.
The replacement position must match the intended allocation
Consider an out-of-range V3 position with rebalancing enabled and aggregator support on its chain. The intended endpoint is an active replacement around the market price. The cost depends on gas, existing allowances and the swap needed to adjust the token ratio.
- Accept the proposed bounds only when their price units match the intended exposure.
- Review the swap's minimum output and price impact before confirming the swap.
- Compare estimated gas with the position's value before confirming the withdrawal.
- Confirm the remaining operations only while the refreshed plan still matches the intended deposit.
A completed on-chain withdrawal leaves assets in the wallet until later steps use them. At completion, the dialog shows the new range, deposited token amounts and wallet remainder. Compare those entries with the intended allocation. The position list updates after subgraph indexing and can lag the completed deposit. If the market price leaves the proposed bounds before deposit, the expected in-range outcome no longer holds. The interface offers a single-sided deposit or, where an aggregator is available, re-centring and swapping the difference. Either choice changes the remaining plan and warrants a fresh cost comparison.
V3 protections target particular sources of LP losses
The rewards machinery can detect and filter malicious just-in-time liquidity, known as JIT liquidity. This protection concerns how the system allocates rewards.
During certain volatility triggers, V3 raises pool trading fees to charge more for adverse arbitrage flow. That mechanism addresses impermanent loss through fees. It does not reimburse every change in a position's value or fix the market price of its tokens. Concentrated liquidity still combines earning opportunities with exposure to the underlying assets.
Stable and volatile curves address the pair's price relationship
V2's stable and volatile pools use different curves for closely correlated and uncorrelated assets. Volatile pools use x × y ≥ k, where x and y represent reserves and k is the invariant benchmark. Stable pools reshape the curve around the assets' close price relationship. This pool-level choice differs from setting a V3 position's bounds.
A stable curve cannot hold two assets at a fixed relative market value. Their correlation can weaken, changing the assumption behind that pool choice. Token decimals also matter when expressing its reserves. After normalizing those reserves, the stable-pool invariant is x³y + y³x ≥ k.
Things people ask about Solidly liquidity pools
How does the 24-hour comparison evaluate a proposed V3 range?
The comparison shows how much of the last 24 hours the pool price spent inside each range. In range, last 24h describes the existing bounds, while Would be in range, last 24h applies the same history to the proposed bounds. Changing the proposed range updates its comparison. These figures describe historical coverage and do not predict future earnings.
Which slippage setting applies to the replacement V3 deposit?
The rebalance interface applies fixed deposit slippage of 2.5% to the replacement position. Its aggregator swap has a separate setting, with 0.1%, 0.5% and 1% presets plus Custom. The swap default follows saved preferences; changing it inside the dialog applies for that browser session. The swap setting therefore does not replace the tolerance that governs the deposit.
Why does a V3 rebalance report a pool or wallet network error?
An error reading the pool and wallet indicates that the interface cannot reach the chain's remote procedure call (RPC) service. A swap-quote error means no aggregator returned a usable route. The separate unsupported-chain message means aggregator swaps have no coverage on that network.
Will Solidly rebalance a position when gas exceeds half its value?
The rebalance interface blocks a plan when estimated gas exceeds half the position's value. It also blocks rebalancing when a position is worth less than about $0.50 or swap price impact exceeds 3%. A less severe gas burden can generate a warning without blocking. Gas estimates reflect the selected chain and the transactions that the plan requires.
Can I resume a V3 rebalance after closing the tab?
An unfinished rebalance can resume from progress saved in the same browser. That record survives a reload or closed tab, remains for up to seven days and clears when the rebalance completes. It does not follow the wallet to another device. Discarding the saved run starts new planning from the assets then available in the wallet.
Are aggregator preferences stored separately for each chain?
The browser stores aggregator preferences separately for each chain. Controls appear when more than one aggregator serves the chain, and at least one must remain enabled. A newly added aggregator starts enabled. Solidly uses the best quote among the aggregators that remain enabled on that chain.