Implementation leads to applying two division operations instead of one compromising the results of the balances involved in a transfer/transferFrom call.
Any call to transfer/transferFrom/mint/burn already invokes the overriden _update due to how ERC20 is implemented.
This is an issue because _update already performs rayDiv() using the up-to-date liquidity index, as intended by the "index-based" design.
With the current setup, each call to transfer() and transferFrom() will result in two division operations, leading to unexpected numerical results.
Furthermore in transferFrom() the function uses a local _liquidityIndex instead of accessing the LendingPool's one, resulting in an outdated index.
Any operation involving the RToken will result in erroneous/unexpected values, comprising the reliability of the protocol as a whole.
Manual review.
The transfer() and transferFrom() overrides should just call their "super" version without performing the division, since the handling of the index is already performed by the overriden _update().
This snippet shows that following a transfer() between two users, the same quantity of 1 ether (taking into account the current index) for the user1 becomes less than the original/intended amount of the transfer due to it being divided once too many times by the liquidity index.
Note that in order for this to work, another bug needs to be fixed by adding something like the following to the constructor of the LendingPool:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.