Beanstalk: The Finale
Beanstalk
DeFiHardhatFoundry
250,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

``receiveToken` isn't called directly in `LibTransfer`

0xbeastboy

Summary

The burnToken function in the LibTransfer library calls LibTransfer.receiveToken instead of calling the receiveToken function directly, despite receiveToken being available within the same contract. This practice introduces unnecessary complexity and potential readability issues.

Vulnerability Details

See the following code:

function burnToken(
IBean token,
uint256 amount,
address sender,
From mode
) internal returns (uint256 burnt) {
// burnToken only can be called with Unripe Bean, Unripe Bean:3Crv or Bean token, which are all Beanstalk tokens.
// Beanstalk's ERC-20 implementation uses OpenZeppelin's ERC20Burnable
// which reverts if burnFrom function call cannot burn full amount.
if (mode == From.EXTERNAL) {
token.burnFrom(sender, amount);
burnt = amount;
} else {
burnt = LibTransfer.receiveToken(token, amount, sender, mode);
token.burn(burnt);
}
}

Impact

The receiveToken function is called with the LibTransfer prefix, despite being available within the same contract. This approach:

  • It makes the code less readable and can confuse developers about the origin and scope of the function.

  • The use of the LibTransfer prefix is redundant and unnecessary since the function is part of the same library.

Tools Used

Manual Reivew

Recommendations

The function receiveToken should be called directly within the burnToken function, removing the unnecessary LibTransfer prefix. This will improve the readability and maintainability of the code.

Updates

Lead Judging Commences

inallhonesty Lead Judge 11 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational/Gas

Invalid as per docs https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity

Support

FAQs

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