Tadle

Tadle
DeFiFoundry
27,750 USDC
View results
Submission Details
Severity: medium
Valid

Protocol Won't Work With Fee-On-Transfer Tokens

[M-03] Protocol Won't Work With Fee-On-Transfer Tokens

Summary

Tokens implementing a fee-on-transfer mechanism, which deduct a fee from the recipient on each transfer, are incompatible with the current implementation of the TokenManager::_transfer function. This incompatibility arises because the _transfer function includes a check to verify whether the recipient's balance has been correctly incremented by the transferred amount. Since fee-on-transfer tokens adjust the recipient's balance after deducting the fee, this check fails, preventing users from depositing or withdrawing these types of tokens.

Vulnerability Details

The problematic check within the _transfer function ensures that the recipient's balance (toBalanceAft) equals the initial balance plus the transferred amount (toBalanceBef + _amount). However, for tokens with a fee-on-transfer feature, the actual balance increase is less due to the fee deduction, causing the check to revert.

function _transfer(
address _token,
address _from,
address _to,
uint256 _amount,
address _capitalPoolAddr
) internal {
uint256 fromBalanceBef = IERC20(_token).balanceOf(_from);
uint256 toBalanceBef = IERC20(_token).balanceOf(_to);
if (
_from == _capitalPoolAddr &&
IERC20(_token).allowance(_from, address(this)) == 0x0
) {
ICapitalPool(_capitalPoolAddr).approve(address(this));
// ICapitalPool(_capitalPoolAddr).approve(_token);
}
_safe_transfer_from(_token, _from, _to, _amount);
uint256 fromBalanceAft = IERC20(_token).balanceOf(_from);
uint256 toBalanceAft = IERC20(_token).balanceOf(_to);
if (fromBalanceAft != fromBalanceBef - _amount) {
revert TransferFailed();
}
@> if (toBalanceAft != toBalanceBef + _amount) {
@> revert TransferFailed();
@> }
}

Impact

The inability to handle fee-on-transfer tokens limits the protocol's compatibility with a broader range of ERC20-compliant tokens, potentially excluding users who wish to interact with these tokens within the protocol.

Proof of Concept

To demonstrate this issue, consider integrating a fee-on-transfer token into the testing environment and attempting to perform operations with it:

Install the library of wierd tokens and import it in test file:

forge install d-xo/weird-erc20 --no-commit

Run the following test in exsiting test suit:

function test_my_FOT() public {
vm.startPrank(user1);
fot = new TransferFeeToken(1000000 ether, 0.1 ether); // total supply and fee
address[] memory tokenAddressList = new address[](1);
tokenAddressList[0] = address(fot);
tokenManager.updateTokenWhiteListed(tokenAddressList, true);
fot.transfer(user, 100.1 ether);
assertEq(fot.balanceOf(user), 100 ether);
vm.startPrank(user);
vm.expectRevert(Rescuable.TransferFailed.selector);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(fot),
1000,
10 * 1e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Turbo
)
);
}

Tools Used

Manual Review

Recommendations

To resolve this issue, consider removing the balance check entirely or modifying it to account for the fee deducted during the transfer. Alternatively, introduce a parameter to specify the fee rate for tokens with a fee-on-transfer mechanism, allowing the protocol to accurately calculate the expected recipient balance post-transfer.

function _transfer(
address _token,
address _from,
address _to,
uint256 _amount,
address _capitalPoolAddr
+ uint256 _feeOnTransfer
) internal {
uint256 fromBalanceBef = IERC20(_token).balanceOf(_from);
uint256 toBalanceBef = IERC20(_token).balanceOf(_to);
if (
_from == _capitalPoolAddr &&
IERC20(_token).allowance(_from, address(this)) == 0x0
) {
ICapitalPool(_capitalPoolAddr).approve(address(this));
// ICapitalPool(_capitalPoolAddr).approve(_token);
}
_safe_transfer_from(_token, _from, _to, _amount);
uint256 fromBalanceAft = IERC20(_token).balanceOf(_from);
uint256 toBalanceAft = IERC20(_token).balanceOf(_to);
if (fromBalanceAft != fromBalanceBef - _amount) {
revert TransferFailed();
}
- if (toBalanceAft != toBalanceBef + _amount) {
+ if (toBalanceAft != toBalanceBef + _amount - _feeOnTransfer) {
revert TransferFailed();
}
}
Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-TokenManager-FOT-Rebasing

Valid medium, there are disruptions to the ability to take market actions. The following functions will be disrupted without the possibiliy of reaching settlement, since the respective offers cannot be created/listed regardless of mode when transferring collateral token required to the CapitalPool contract or when refunding token from user to capital pool during relisting. So withdrawal is not an issue - `createOffer()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L96-L102) - `listOffer()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L355-L362) - `relistOffer()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L515-L521) - `createTaker()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L831-L836) I believe medium severity is appropriate although the likelihood is high and impact is medium (only some level of disruption i.e. FOT tokens not supported and no funds at risk)

Support

FAQs

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