# VoterProxy incorrectly assumes a 1-1 mapping between the gauge and the LP tokens.

VoterProxy.withdrawAll assumes 1 gauge token equals 1 LP token, so gauges with a staking_factor (e.g. Angle) cause wrong withdrawal amounts and fund loss.

- Payout: Contest reward
- Severity: medium
- Program: veToken Finance
- Credited: Picodes
- Disclosed: 2022-10-25
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-vetoken-findings/issues/51
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-vetoken%3AM-21
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error

**Target:** VoterProxy.sol withdrawAll / balanceOfPool gauge accounting
**Root cause:** withdrawAll computes the amount to withdraw as gauge balance plus LP token balance held by the contract, assuming a 1:1 mapping between gauge tokens and underlying LP tokens. Some gauges apply a staking_factor so this ratio does not hold.
**Steps:**
1. Read VoterProxy.sol L270: `uint256 amount = balanceOfPool(_gauge).add(IERC20(_token).balanceOf(address(this)));`
2. Observe balanceOfPool returns the gauge token balance, treated as LP token amount
3. Compare against a gauge like 0x3785Ce82be62a342052b9E5431e9D3a839cfB581 where total supply != LP token balance held, due to a staking_factor
4. Call withdrawAll on such a gauge; computed amount mismatches actual LP tokens, over/under-withdrawing
**How found:** Code reading of withdrawAll's amount computation, spotting the implicit 1 gauge token = 1 LP token assumption, then verifying against a real gauge contract on Etherscan whose total supply differs from its LP token balance due to a staking_factor.
**Exploitation:** Not demonstrated against live funds; requires veToken to integrate a rebasing/non-1:1 gauge (e.g. Angle Protocol). withdrawAll would then withdraw an incorrect amount, leaving funds stuck or lost.
**Insight:** When a wrapper computes withdrawal amounts from gauge/share balances, verify the share-to-underlying exchange rate on real integrated contracts rather than assuming 1:1; rebasing or staking_factor gauges break the math.