LP token balanceOf used for pricing
Uniswap (v2 + v3)'s assessment for RD-F-061 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Neither V2 nor V3 uses LP token balanceOf for pricing. V2 pricing uses internal _reserve0/_reserve1 state vars (updated only via mint/burn/swap/sync — donation does NOT change reserves until next sync). V3 pricing uses sqrtPriceX96 from AMM invariant. Both read token balanceOf post-swap only for transfer validation, not price determination. Neither version is vulnerable to donation-manipulation of its own pricing.
Detail #
UniswapV2Pair.sol: _reserve0/_reserve1 are private state updated only in _update(); balanceOf() is read in mint/burn/skim/sync for reserve reconciliation, not in price calculation. UniswapV3Pool.sol: swap callback reads balance0Before/balance1Before for post-swap transfer validation only — price is already set from tick math before these reads occur.
Sources #
- GitHubUniswapV3Pool.sol — balanceOf usage in swap callback (transfer validation, not pricing)UniswapV3Pool.sol swap callback: balance0Before = balance0() used to verify slippage only after sqrtPriceX96 is already determined by tick math. Not a pricing oracle pattern.retrieved 2026-05-12
- UniswapV2Pair.sol — reserve state vars vs balanceOf usage patternUniswapV2Pair.sol: _reserve0/_reserve1 are private state vars; balanceOf not used for swap pricing; V3 swap callback: balance0Before used for transfer validation post-price-determination.retrieved 2026-05-12
Methodology #
Determine whether protocol pricing is derived from the `balanceOf` of LP tokens in a contract (manipulable by direct token transfer / donation).
See the full factor methodology and distribution across all protocols →