Rewards are always lost and locked in GaugeV3.sol due to precision loss in positionPeriodsSecondsInRange() and cachePeriodEarned() #189
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
edited-by-warden
🤖_primary
AI based primary recommendation
🤖_06_group
AI based duplicate group recommendation
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-10-ramses-exchange/blob/4a40eba36bc47eba8179d4f6203a4b84561a4415/contracts/CL/core/libraries/Position.sol#L261
https://github.com/code-423n4/2024-10-ramses-exchange/blob/4a40eba36bc47eba8179d4f6203a4b84561a4415/contracts/CL/gauge/GaugeV3.sol#L321
Vulnerability details
Proof of Concept
Below provided is a POC with two test cases. The second case proves the periodSecondsInsideX96 of a position is lesser than what it should be due to the precision loss here. The first case proves that since the periodSecondsInsideX96 is lesser and the mulDiv operation in GaugeV3 here is prone to precision loss as well, the ultimate rewards received are lesser, which is asserted in
testGaugeIssue
as well.If we assume WETH as the reward token, the loss of rewards would be 16534391534392 wei i.e. 0.000016534391534392 ether, which is 0.04 USD (at current price of USD 2580/ETH). This means that for every claim, we would lose around 0.04 USD on average per claim call, which remains locked in the GaugeV3 contract. After only 10000 claim calls, the loss would be 400 USD. The higher the interactions, the higher the tokens permanently locked in the GaugeV3 contract.
The issue is being deemed as Medium-severity since:
reward accounting being accurate and not substantially inflated or deflated from reality are crucial.
Here are the logs/traces for each test:
testGaugeIssue
testPositionPeriodsSecondsInRangeIssue
How to use this POC:
test
folder and name itTestPrecisionLoss.sol
forge test --mt testGaugeIssue -vvvvv
andforge test --mt testPositionPeriodsSecondsInRangeIssue -vvvvv
Recommended Mitigation Steps
Consider introducing a function in GaugeV3, which only allows the
accessManager
to rescue reward tokens present in the contract, provided the reward token has been removed. Rescuing the tokens should also be handled by theaccessManager
to ensure decentralized governance during the whole processAssessed type
Decimal
The text was updated successfully, but these errors were encountered: