MyCut
First Flight #23
Beginner FriendlyFoundry
100 EXP
View results
Previous Next
Submission Details
Severity: high
Invalid

Compatibility issues with some ERC20 token implementations

elprofesor

Summary

After creating a contest, the contest manager is expected to add rewards to it. However, due to the token address being wrapped into the IERC20 interface, this action will revert and make it impossible to fund contests with certain tokens that do not conform strictly to the ERC20 standard.

Vulnerability Details

To add a reward to the pot, the manager calls the fundContest function:

function fundContest(uint256 index) public onlyOwner {
Pot pot = Pot(contests[index]);
@> IERC20 token = pot.getToken();
uint256 totalRewards = contestToTotalRewards[address(pot)];
​
if (token.balanceOf(msg.sender) < totalRewards) {
revert ContestManager__InsufficientFunds();
}
​
@> token.transferFrom(msg.sender, address(pot), totalRewards);
}

The issue arises because some tokens (e.g., USDT, BNB, OMG) do not return a boolean value on transfer operations. Wrapping these tokens in the IERC20 interface, which expects a boolean return value, will cause the transaction to revert.

Impact

The contest manager is not able to add as a reward any of the tokens that do not return a boolean on transfer.

Tools Used

Manual Code Review

Recommendations

Use the SafeERC20 library implementation from OpenZeppelin and call safeTransfer or safeTransferFrom when handling ERC20 tokens in both the Pot and ContestManager contracts. This will provide a more robust and compatible implementation for a variety of ERC20 token implementations.

Updates

Lead Judging Commences

equious Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Design choice

Support

FAQs

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