The mint
function in the RToken
contract is designed to mint interest-bearing tokens (RToken
) to a user when they deposit assets into the Reserve Pool. The function is documented to return four values:
isFirstMint
: Whether this is the first mint for the recipient.
amountScaled
: The amount of scaled tokens minted.
totalSupply
: The new total supply after minting.
amountToMint
: The amount of underlying tokens minted.
However, the implementation of the function returns the second and fourth values in reverse order, leading to a mismatch between the documented behavior and the actual behavior. This inconsistency could cause confusion or errors in dependent contracts or external systems that rely on the function's return values.
The burn
function is designed to burn RToken
from a user and transfer the corresponding underlying asset to a specified recipient. The function is documented to return three values:
amountScaled
: The amount of scaled tokens burned.
totalSupply
: The new total supply after burning.
amount
: The amount of underlying asset transferred.
However, the implementation of the function returns worng value for the first param, leading to a mismatch between the documented behavior and the actual behavior. This inconsistency could cause confusion or errors in dependent contracts or external systems that rely on the function's return values.
The mint
function returns the following values:
amountToMint
: Represents the underlying tokens (e.g., the amount of the asset deposited into the Reserve Pool).
amountScaled
: Represents the scaled tokens (e.g., the amount of RToken
minted, adjusted by the liquidity index).
However, the function's documentation states that the second return value should be the scaled tokens (amountScaled
), and the fourth return value should be the underlying tokens (amountToMint
). This mismatch between the implementation and the documentation creates a logical inconsistency.
The burn
function returns the following values:
The first return value is amount
, which represents the underlying tokens (e.g., the amount of the asset transferred to the recipient).
The third return value is also amount
, which is redundant and does not match the documented behavior.
According to the documentation, the first return value should be the scaled tokens burned (amountScaled
), and the third return value should be the underlying tokens transferred (amount
).
Incorrect Assumptions: External contracts or systems that rely on the mint
function's return values may misinterpret the scaled and underlying token amounts, leading to incorrect calculations or logic.
Integration Issues: Dependent contracts that expect the documented behavior may fail or behave unexpectedly when interacting with the mint
and burn
functions .
User Confusion: Developers or auditors reviewing the code may be misled by the documentation, leading to misunderstandings about the function's behavior.
The impact is Medium because external contracts or systems that rely on the mint
or burn
function's return values may misinterpret the scaled and underlying token amounts, leading to incorrect calculations or logic, the likelihood is High, so the severity is Medium.
Manual Review
To resolve this issue, swap the second and fourth return values in the mint
function to align with the documentation:
update the burn
function to return the correct values as documented:
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.