A snuggle rebalance moves an out-of-range Uniswap V3 or PancakeSwap V3 position back next to the current price — without a swap. No swap fee, no slippage, no selling into a bad quote. It uses only the token you already hold.
Traditional rebalancing on V3 is a swap-then-redeposit: you sell some of the token you have, buy some of the other token, and open a new centered position. That costs the pool's swap fee plus whatever slippage the current depth gives you — on a thin pool or a fast market, that's painful.
A snuggle avoids the swap entirely. If price moved up and you now hold only Token A, we open a new position just above the new price, same width as before, 100% in Token A. If price moved down and you now hold only Token B, we open just below the new price with Token B. The position still earns fees — it just earns them on one side first until price trades back through, which also naturally rebalances you back to two-sided.
Three conditions all have to be true before the keeper fires a snuggle:
The keeper checks about every 1–3 minutes, best effort. No snuggle time is guaranteed — see the choosing settings article for how width and delay interact.
Let your old range be [L, H] at width W% around the pre-move price P₀, so L = P₀·(1 − W/2) and H = P₀·(1 + W/2). Suppose price drifts up and exits above H, settling at some new price P₁ > H. The snuggle opens a new position of the same width just past P₁:
Where ε is a tiny buffer so the new range starts just above live price (never crossing it, which would require a swap). The symmetric case runs below price if the move was downward.
Since you only hold Token A at this point, the new position is 100% Token A deposited into a range that is entirely above the current price — perfectly valid on V3. The moment price trades up into that range, you earn fees; the moment it trades back below the range, you've been naturally rebalanced to all Token B at a higher price than you snuggled at. Repeat until price returns to the original band.
Snuggling moves your liquidity; it doesn't undo the IL that was realized when price exited. If ETH 2x'd and you're now 100% USDC, you missed the ETH upside — a snuggle keeps you earning fees from here, but can't retrieve what IL took. See our impermanent loss article for the full math.
A snuggle will happily chase price in whichever direction it keeps going. If you want to stop out at a drawdown threshold instead of chasing, that's the capital-preservation stop-loss feature — separate opt-in.
A snuggle depends on a usable 30-minute TWAP. On a pool with sparse oracle history (brand new, low-volume), the TWAP check won't pass and the snuggle won't fire — you'd sit out of range until swaps warm the oracle. QuantumPools provisions oracle rings on under-cardinality pools during vault setup specifically to avoid this.
Keepers can only call narrowly-scoped vault functions — they can't withdraw user funds, change performance fees, add pools, or alter range parameters. Every one of those "sensitive" calls runs through a 48-hour TimelockController owned by a 2-of-2 Safe multisig. Keepers are added/removed only through that same timelock. The V2.1 vault contract was audited by Hashlock and a parity test (QuantumVaultV2.bscParity.t.sol) enforces that the deployed bytecode matches the audited source.