# TWA update is not correct

Maverick Pool.swap clips delta.endSqrtPrice when updating TWA, so the fractional tick contribution is always positive, corrupting moving-bin decisions.

- Payout: Audit contest
- Severity: medium
- Program: Maverick
- Found by: hansfriese
- Disclosed: 2023-05-03
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2022-12-stealth-project#m-07
- Library page: http://bugbountylibrary.com/r/c4%3A2022-12-stealth-project%3AM-07
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error

**Target:** Pool.sol swap() TWA update logic
**Root cause:** The fractional part of the TWA update uses Math.clip(delta.endSqrtPrice, delta.sqrtLowerTickPrice), forcing the term non-negative even when endSqrtPrice falls outside the bin range, so the activeTick contribution is biased upward.
**Steps:**
1. Inspect Pool.sol swap() line 294 where twa.updateValue is called with currentState.activeTick * SCALE + int256(Math.clip(delta.endSqrtPrice, delta.sqrtLowerTickPrice).div(delta.sqrtUpperTickPrice - delta.sqrtLowerTickPrice)).
2. Note the clip() bounds the numerator to at least sqrtLowerTickPrice, so the fractional term can never be negative.
3. Observe endSqrtPrice can legitimately fall outside (sqrtLowerTickPrice, sqrtUpperTickPrice), e.g. via accuracy loss in endSqrtPrice computation.
4. Conclude the TWA is updated with a biased fractional tick, affecting subsequent moving-bin decisions.
**How found:** Code review of the swap() TWA update; noticed the clip() wrapper on delta.endSqrtPrice makes the fractional contribution always positive, contradicting the intended two-way contribution to activeTick.
**Insight:** When auditing TWAP/TWA accumulators, check whether any clip/min/max on the price term silently removes sign information; a one-sided clamp on a value that should be signed biases the accumulator and can misdirect bin movement.