Core Contracts

Summary

The RToken contract has a double scaling issue in its transfer functions where amounts are scaled down by the liquidity index twice - once in the transfer function and again in the _update function. This leads to incorrect transfer amounts.

Vulnerability Details

The OpenZeppelin ERC20 implementation calls _update() from its transfer functions, creating this double scaling issue.

1. The transfer function scales the amount by dividing it by the normalized income:

   function transfer(address recipient, uint256 amount) public override(ERC20, IERC20) returns (bool) {

   uint256 scaledAmount = amount.rayDiv(ILendingPool(_reservePool).getNormalizedIncome());

   return super.transfer(recipient, scaledAmount);

   }

2. However, the _update function, which is called by the parent ERC20 implementation during transfer, also performs scaling:

   function _update(address from, address to, uint256 amount) internal override {

   uint256 scaledAmount = amount.rayDiv(ILendingPool(_reservePool).getNormalizedIncome());

   super._update(from, to, scaledAmount);

   }

3. This means that when a transfer is made:

• First scaling: amount is divided by normalized income in transfer()

• Second scaling: the already scaled amount is divided again by normalized income in _update()

Impact

This double scaling means users will receive significantly less tokens than intended when transfers occur.

Tools Used

• Manual code review

Recommendations

1. Remove scaling from transfer and transferFrom functions

2. Keep scaling in _update function