Skip to content

Latest commit

 

History

History
45 lines (26 loc) · 1.51 KB

039.md

File metadata and controls

45 lines (26 loc) · 1.51 KB

Fast Khaki Raccoon

High

No decimal normalisation upon calling TokenRewards::depositFromPairedLpToken()

Summary

No decimal normalisation upon calling TokenRewards::depositFromPairedLpToken()

Root Cause

Upon calling TokenRewards::depositFromPairedLpToken(), we have the following code:

uint256 _amountOut = _token0 == PAIRED_LP_TOKEN ? (_rewardsPriceX96 * _amountTkn) / FixedPoint96.Q96 : (_amountTkn * FixedPoint96.Q96) / _rewardsPriceX96;

The priceX96 is inverted if needed. However, there is no decimal normalisation done at any point during the function execution. Thus, if the paired LP token and the reward token are in different decimals, the result will be completely incorrect.

NOTE: The reward token and the paired LP token being in different decimals is completely expected. The developer has mentioned in a public channel that USDC will be used which has 6 decimals.

Internal Pre-conditions

No response

External Pre-conditions

No response

Attack Path

  1. TokenRewards::depositFromPairedLpToken() is called and the paired LP token, USDC, has to be converted to an 18-decimal reward token
  2. The amount out will be in 6 decimals which will result in a HUGE slippage allowed, practically the slippage protection will be non-existent
  3. The other scenario would be if the reward token has less decimals than the paired LP token, which will simply cause a revert

Impact

Theft of funds or reverts

PoC

No response

Mitigation

Convert the decimals accordingly