# LamboRebalanceOnUniswap::_getTokenInOut formula used to compute rebalancing amount is wrong for a UniV3 pool

LamboRebalanceOnUniswap computes rebalance amount with a constant-sum midpoint formula, ignoring UniV3 tick liquidity and constant-product slippage, so the peg rebalance is wrong.

- Payout: Contest reward
- Severity: medium
- Program: Lambo.win
- Credited: Infect3d
- Disclosed: 2025-02-03
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-12-lambowin#m-02
- Library page: https://bugbountylibrary.com/r/c4%3A2024-12-lambowin%3AM-02
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** LamboRebalanceOnUniswap.sol rebalance contract on Uniswap V3
**Root cause:** _getTokenInOut uses (wethBalance+vethBalance)/2 as target, assuming constant-sum AMM, and reads raw pool token balances that include liquidity in inactive ticks unrelated to the active price.
**Steps:**
1. Read `_getTokenBalances()`: returns `IERC20(weth).balanceOf(uniswapPool)` and veth balance, which include inactive-tick liquidity.
2. Read `_getTokenInOut()`: `targetBalance = (wethBalance + vethBalance) / 2`, then `amountIn = |balance - targetBalance|`.
3. Example: WETH=1000, vETH=900 -> target=950, amountIn=50 vETH; swapping 50 vETH does not yield 50 WETH due to constant-product slippage.
4. Add liquidity in distant ticks to further skew measured balances away from active price.
**How found:** Code review of the rebalance math: noticed the midpoint formula implies x+y=k (constant sum) while the pool is constant-product x*y=k, and that raw balanceOf includes out-of-range tick liquidity not tied to price.
**Insight:** When auditing rebalance/peg logic on UniV3, never trust raw pool token balances as price proxies: out-of-range tick liquidity inflates them, and the correct target must be derived from sqrtPrice/tick math, not a linear midpoint.