# UniswapV3 sqrtRatioLimit doesn't provide slippage protection and will result in partial swaps

IchiSpell used UniswapV3 sqrtRatioLimit as slippage protection, but it only partially fills swaps, leaving tokens in the contract stealable by anyone.

- Payout: Contest reward
- Severity: high
- Program: Blueberry
- Credited: 0x52
- Disclosed: 2023-04-07
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-04-blueberry-judging/issues/132
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-blueberry%3AH-9
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** IchiSpell.sol UniswapV3 swap integration
**Root cause:** UniswapV3 sqrtRatioLimit halts the swap early rather than reverting when the price limit is reached, so it does not enforce a minimum output; the spell treats it as slippage protection.
**Steps:**
1. Call the IchiSpell function that performs the swap with amountToSwap > 0.
2. Observe it computes deltaSqrt = sqrtRatioLimit * sellSlippage / DENOMINATOR and passes sqrtRatioLimit ± deltaSqrt as the limit.
3. UniswapV3 pool swap stops when the limit is hit, partially filling the swap instead of reverting.
4. Unsold tokens remain in the spell contract and can be taken by anyone.
**How found:** Code review of IchiSpell swap logic; recognized the documented UniswapV3 behavior that sqrtRatioLimit ends swaps prematurely rather than reverting, so it cannot serve as slippage protection.
**Exploitation:** Attacker waits for or induces a swap that hits the sqrtRatioLimit, causing a partial fill; leftover tokens stranded in the contract are then swept by the attacker.
**Insight:** When integrating UniswapV3, sqrtRatioLimit is a price bound that causes partial fills, not a revert-on-slippage guard; always check the actual received amount against a user-supplied minimum and revert otherwise.