Tadle

Summary

The vulnerability identified in the TokenManager contract is related to the handling of ERC20 tokens that impose a fee on transfers. The current implementation of the _transfer() function does not account for tokens that charge a fee, which can result in incorrect balance calculations and transaction failures.

Vulnerability Details

The vulnerability arises from the assumption that the amount transferred is equal to the amount received by the recipient. However, certain ERC20 tokens charge a fee on every transfer() or transferFrom() call. In the TokenManager contract, the _transfer() function assumes the full transfer amount is received. For tokens with transfer fees, this assumption leads to inaccurate calculations, as the actual received amount is less than the intended transfer amount.

Code Snippet

Impact

The impact of this vulnerability is significant, as it can cause transactions to fail when interacting with tokens that impose a transfer fee. This includes popular tokens like STA and PAXG. If the transfer fee is toggled on in the future for tokens like USDT and USDC, users may find themselves unable to withdraw their funds due to the transfer failures.

Proof Of Concept

Some tokens take a transfer fee (STA, PAXG) and there are some that currently
do not but might do so in the future (USDT, USDC).
Let’s look at the following scenario:

1. Alice tries to transfer tokens to capital pool.

2. Some checks are executed in TokenManager.sol::_transfer():

Transfer will always fail, since the transferredAmount will be less than amount due to the fee.

USDT is an ERC20 token that has togglable transfer fees, but for now the fee is set to 0 (see
the contract here: https://etherscan.io/address/0xdAC17F958D2ee523a2206206994597C13D831ec7#code ).
If user transfer USDT and later on they change the transfer fee, user will be not able to withdraw
their funds.

Tools Used

Manual review

Recommendations

Implement a logic that supports ERC20 tokens with fees.