Potential Misunderstanding - Interest Rate Initialization in transfer and transferFrom Functions

[bala-Blockchian]

Description

The transfer and transferFrom functions in the RebaseToken.sol contract include a check that initializes the interest rate for a recipient if their balance is zero:

if (balanceOf(_recipient) == 0) {
    s_userInterestRate[_recipient] = s_userInterestRate[msg.sender];
}

The concern raised is whether this logic could be exploited by a user to gain an unfair advantage in interest accumulation. Specifically, it was suggested in the video that a user could:

1. Enter the protocol early and deposit a small amount to gain a higher interest rate (as interest reduces over time).
2. Later, create a new address and deposit a large amount into it.
3. Transfer a small amount from the original address to the new address to initialize the new address’s interest rate at the higher rate from the original address.

However, upon reviewing the logic and associated functions, it appears that this potential vulnerability does not exist due to the following reasons:

1. balanceOf Function:

   function balanceOf(address _user) public view override returns (uint256) {
       uint256 currentPrincipalBalance = super.balanceOf(_user); // ERC20 balance of the user
       if (currentPrincipalBalance == 0) {
           return 0;
       }
       return (currentPrincipalBalance * _calculateUserAccumulatedInterestSinceLastUpdate(_user)) / PRECISION_FACTOR;
   }

   Explanation:
   In balanceOf:
   The balanceOf function ensures that if a user has previously minted, their balance will reflect the accumulated interest. As a result, the function will not return 0 for accounts that have participated in the protocol. Additionally, the principal amount is updated after the initial mint.

2. Interest Calculation:

   • The _calculateUserAccumulatedInterestSinceLastUpdate function uses the formula:

   function _calculateUserAccumulatedInterestSinceLastUpdate(address _user)
       internal
       view
       returns (uint256 linearInterest) {
       uint256 timeDifference = block.timestamp - s_userLastUpdatedTimestamp[_user];
       linearInterest = (s_userInterestRate[_user] * timeDifference) + PRECISION_FACTOR;
   }

   Explanation:
   In _calculateUserAccumulatedInterestSinceLastUpdate:
   The _calculateUserAccumulatedInterestSinceLastUpdate function ensures that the accumulated interest is calculated based on the s_userLastUpdatedTimestamp[_user]. This timestamp is initialized inside the mint function and is used to determine the time difference for calculating the interest.

Given the above, it appears that the balanceOf function and interest calculation logic prevent users from exploiting the protocol by initializing new accounts with inflated interest rates derived from other accounts. If the recipient has previously interacted with the protocol, their s_userInterestRate and s_userLastUpdatedTimestamp will already reflect their historical activity.

Note:
I’m not entirely sure if this point is right, so I may be missing something. Kindly assess me if I am right in my analysis.