VoterProxy
incorrectly assumes a 1-1 mapping between the gauge and the LP tokens.
#51
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
question
Further information is requested
sponsor acknowledged
Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Lines of code
https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VoterProxy.sol#L270
https://github.com/code-423n4/2022-05-vetoken/blob/2d7cd1f6780a9bcc8387dea8fecfbd758462c152/contracts/VoterProxy.sol#L140
Vulnerability details
Impact
When calling
withdrawAll
, to compute the amount to withdraw, the contract checks the balance of gauge tokens and assume that1 gauge token = 1 LP token
by doinguint256 amount = balanceOfPool(_gauge).add(IERC20(_token).balanceOf(address(this)));
. Overall this assumption may not hold and this would lead to a loss of funds when callingwithdrawAll
.Proof of concept
Indeed this is false in some cases, check for example https://etherscan.io/address/0x3785Ce82be62a342052b9E5431e9D3a839cfB581 where the total supply is not the same as the balance of LP tokens held by the contract. You can also check the contract code where you can see there is a
staking_factor
between the balance and the underlying LP token balance.Mitigation steps
Use the total supply of
pool.token
which is a better proxy to know how much to withdraw when withdrawing all.The text was updated successfully, but these errors were encountered: