Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: low
Valid

Incorrect return value order in RToken mint function causes deposit amount mismatch

Summary

The ReserveLibrary.deposit function misinterprets the return values from the RToken.mint function. While the deposit function expects the tuple to be ordered as
(isFirstMint, amountScaled, newTotalSupply, amountUnderlying),
the mint function actually returns
(isFirstMint, amountToMint, newTotalSupply, amountScaled).
As a result, the deposit function assigns amountMinted to the second returned value (i.e. amountToMint) instead of the intended last value (amountScaled), leading to incorrect accounting of minted RTokens.

Vulnerability Details

  1. Return Value Mismatch:

    In the deposit function, the following call is made:

    (bool isFirstMint, uint256 amountScaled, uint256 newTotalSupply, uint256 amountUnderlying) = IRToken(reserve.reserveRTokenAddress).mint(
    address(this), // caller
    depositor, // onBehalfOf
    amount, // amount
    reserve.liquidityIndex // index
    );
    amountMinted = amountScaled;

    However, the mint function returns:

    return (isFirstMint, amountToMint, totalSupply(), amountScaled);

    The deposit function mistakenly treats amountToMint as if it were the scaled minted amount.

  2. Incorrect Deposit Value Calculation:

    Due to the incorrect assignment (amountMinted = amountScaled where amountScaled is actually the fourth return value in the mint function), the deposit operation records the minted amount inaccurately. This discrepancy can lead to errors in user balances and reserve accounting.

Impact

The minted amount recorded for depositors does not reflect the correct scaled value

Although not immediately exploitable for fund theft, incorrect state updates could be manipulated to distort user balances and system liquidity, thereby impacting downstream financial operations.

Stakeholders may lose confidence in the system if the minted token amounts do not match expectations, undermining the protocol’s reliability and transparency.

Proof-of-Concept (POC) Example

  1. Normal Scenario:

    • A user deposits 100 units.

    • The deposit function calls mint expecting (isFirstMint, amountScaled, newTotalSupply, amountUnderlying).

    • The mint function returns (true, 100, totalSupply, scaledValue) where scaledValue is computed as 100.rayDiv(liquidityIndex).

  2. Issue:

    • The deposit function assigns amountMinted = 100 (the second value) instead of scaledValue (the fourth value).

    • This leads to the event Deposit(depositor, 100, 100) being emitted, even though the actual scaled minted amount is scaledValue.

  3. Result:

    • The user’s RToken balance and the reserve’s state do not accurately reflect the scaled deposit, causing downstream miscalculations in liquidity and interest accrual.

Tools Used

Manual review

Recommendations

Correct the Return Value Handling:

  • Adjust the destructuring in the deposit function to match the actual order of returns from mint. For example:

    (bool isFirstMint, uint256 amountToMint, uint256 newTotalSupply, uint256 amountScaled) = IRToken(reserve.reserveRTokenAddress).mint(
    address(this),
    depositor,
    amount,
    reserve.liquidityIndex
    );
    amountMinted = amountScaled;
  • Alternatively, update the mint function to return the values in the order expected by the deposit function.

Updates

Lead Judging Commences

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RToken::mint doesn't return data in the right order, making the protocol emit wrong events

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RToken::mint doesn't return data in the right order, making the protocol emit wrong events

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!