Trouble Calling transfer and transferForm function of USDT token From Another Smart Contract, Why?

Hello everyone,

I'm encountering an issue with calling the transfer and transferToken functions from this below smart contract. I've deployed the contract in question, but attempts to transfer USDT from it using these functions have failed. I've thoroughly reviewed the code and am unable to pinpoint the exact reason for the failure.

Could someone please offer insights into why these functions might not be executing as expected when called from another smart contract? Any assistance or suggestions on how to debug and resolve this issue would be greatly appreciated.

Thank you in advance for your help!

Bridge Contract Code Where I try to call USDT token transfer and transferFrom function.

TokenBridge.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.9;

import "./Ownable.sol";
import "./IERC20.sol";

contract BridgeContract is Ownable {
    
    uint256 private numberOfTransfer;

    address public controller;

    constructor(address _controller) {
        controller = _controller;
    }

    function updateControler(address _controller) public onlyOwner {
        controller = _controller;
    }
    
    function getNumberOfTransfer() public view returns (uint256) {
        return numberOfTransfer;
    }

    function transfer(address tokenAddress, uint256 amount, address to, uint256 nonce) public {
        require(msg.sender == controller, "Only for controller");
        require(tokenAddress != address(0), "Invalid token address");
        require(to != address(0), "Invalid recipient address");
        require(nonce == numberOfTransfer + 1, "The previous nonce is missing");

        IERC20 token = IERC20(tokenAddress);

        bool success = token.transfer(to, amount);
        require(success, "ERC20 transfer failed");

        numberOfTransfer = numberOfTransfer + 1;
    }

    function transferFrom(address tokenAddress, uint256 amount, address from, address to, uint256 nonce) public {
        require(msg.sender == controller, "Only for controller");
        require(tokenAddress != address(0), "Invalid token address");
        require(to != address(0), "Invalid recipient address");
        require(nonce == numberOfTransfer + 1, "The previous nonce is missing");

        IERC20 token = IERC20(tokenAddress);

        bool success = token.transferFrom(from, to, amount);
        require(success, "ERC20 transfer failed");

        numberOfTransfer = numberOfTransfer + 1;
    }
    
    function transferTokens(address tokenAddress, address to, uint256 amount) public onlyOwner {
        require(tokenAddress != address(0), "Invalid token address");
        require(to != address(0), "Invalid recipient address");

        IERC20 token = IERC20(tokenAddress);

        bool success = token.transfer(to, amount);
        require(success, "ERC20 transfer failed");
    }
}

Context.sol

pragma solidity ^0.8.9;

// SPDX-License-Identifier: MIT

/*
 * @dev Provides information about the current execution context, including the
 * sender of the transaction and its data. While these are generally available
 * via msg.sender and msg.data, they should not be accessed in such a direct
 * manner, since when dealing with GSN meta-transactions the account sending and
 * paying for execution may not be the actual sender (as far as an application
 * is concerned).
 *
 * This contract is only required for intermediate, library-like contracts.
 */
abstract contract Context {
    function _msgSender() internal view virtual returns (address payable) {
        return payable(msg.sender);
    }

    function _msgData() internal view virtual returns (bytes memory) {
        this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691
        return msg.data;
    }
}

IERC20.sol

pragma solidity ^0.8.9;

// SPDX-License-Identifier: MIT

interface IERC20 {
    function transfer(address recipient, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
}

Ownable.sol

pragma solidity ^0.8.9;

// SPDX-License-Identifier: MIT

import "./Context.sol";

/**
 * @dev Contract module which provides a basic access control mechanism, where
 * there is an account (an owner) that can be granted exclusive access to
 * specific functions.
 *
 * By default, the owner account will be the one that deploys the contract. This
 * can later be changed with {transferOwnership}.
 *
 * This module is used through inheritance. It will make available the modifier
 * `onlyOwner`, which can be applied to your functions to restrict their use to
 * the owner.
 */
abstract contract Ownable is Context {
    address private _owner;

    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    /**
     * @dev Initializes the contract setting the deployer as the initial owner.
     */
    constructor () {
        address msgSender = _msgSender();
        _owner = msgSender;
        emit OwnershipTransferred(address(0), msgSender);
    }

    /**
     * @dev Returns the address of the current owner.
     */
    function owner() public view returns (address) {
        return _owner;
    }

    /**
     * @dev Throws if called by any account other than the owner.
     */
    modifier onlyOwner() {
        require(_owner == _msgSender(), "Ownable: caller is not the owner");
        _;
    }

    /**
     * @dev Leaves the contract without owner. It will not be possible to call
     * `onlyOwner` functions anymore. Can only be called by the current owner.
     *
     * NOTE: Renouncing ownership will leave the contract without an owner,
     * thereby removing any functionality that is only available to the owner.
     */
    function renounceOwnership() public virtual onlyOwner {
        emit OwnershipTransferred(_owner, address(0));
        _owner = address(0);
    }

    /**
     * @dev Transfers ownership of the contract to a new account (`newOwner`).
     * Can only be called by the current owner.
     */
    function transferOwnership(address newOwner) public virtual onlyOwner {
        require(newOwner != address(0), "Ownable: new owner is the zero address");
        emit OwnershipTransferred(_owner, newOwner);
        _owner = newOwner;
    }
}

The transection Fail without any message.

This is the function-call as shown in your transaction on etherscan:

Function: transfer(address tokenAddress,uint256 amount,address to,uint256 nonce)

MethodID: 0x335a9406
[0]:  000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7
[1]:  00000000000000000000000000000000000000000000000000000000000f4240
[2]:  000000000000000000000000e078131630094ab5977a6b5d8f2271f9036d8bdb
[3]:  0000000000000000000000000000000000000000000000000000000000000001

Which we can interpret as:

tokenAddress = 0xdac17f958d2ee523a2206206994597c13d831ec7
amount       = 0xf4240 = 1000000
to           = 0xe078131630094ab5977a6b5d8f2271f9036d8bdb
nonce        = 0x1 = 1

In your contract's transfer function, you are requiring that nonce == numberOfTransfer + 1:

require(nonce == numberOfTransfer + 1, "The previous nonce is missing");

We can check the value of variable numberOfTransfer by calling function getNumberOfTransfer:

function getNumberOfTransfer() public view returns (uint256) {
    return numberOfTransfer;
}

When we do that in your contract on etherscan, we can see that the value of this variable is 2:

So the expression nonce == numberOfTransfer + 1 is evaluated as 1 == 2 + 1, hence false.

You can resolve this failure by passing nonce = 3 instead of nonce = 1.

Hi
Thanks for your reply.

If you see I was try to call this function before 2 others transaction, on that time the nonc was 0 so I have called with correct nonce, and if the nonce wrong the error message will be "The previous nonce is missing" as per the code require(nonce == numberOfTransfer + 1, "The previous nonce is missing");

You are correct, but etherscan doesn't always show the exact error-message, which has led me to speculate that this is the problem (which it is not, clearly by the other fact that you've mentioned, about two other successful transactions leading the nonce to its current value).

Anyways, comparing the failed transaction with the two successful transactions, one notable difference is the target token contract, which is:

  • USDT in the case of the failed transaction
  • USDC in the case of the successful transaction

Since your contract function calls the transfer function on the target token contract, we would want to check for any differences between the transfer function in these two token contracts.

Now, as you can see in the USDC link above, this is a Proxy contract, which makes it a little more difficult to find the relevant source code.

Luckily, etherscan knows to point us to the corresponding Implementation contract (aka Logic contract), so we can easily compare the two transfer functions...

USDT's transfer function:

    function transfer(address _to, uint _value) public onlyPayloadSize(2 * 32) {
        uint fee = (_value.mul(basisPointsRate)).div(10000);
        if (fee > maximumFee) {
            fee = maximumFee;
        }
        uint sendAmount = _value.sub(fee);
        balances[msg.sender] = balances[msg.sender].sub(_value);
        balances[_to] = balances[_to].add(sendAmount);
        if (fee > 0) {
            balances[owner] = balances[owner].add(fee);
            Transfer(msg.sender, owner, fee);
        }
        Transfer(msg.sender, _to, sendAmount);
    }

USDC's transfer function:

    function transfer(address to, uint256 value)
        external
        override
        whenNotPaused
        notBlacklisted(msg.sender)
        notBlacklisted(to)
        returns (bool)
    {
        _transfer(msg.sender, to, value);
        return true;
    }

    function _transfer(
        address from,
        address to,
        uint256 value
    ) internal override {
        require(from != address(0), "ERC20: transfer from the zero address");
        require(to != address(0), "ERC20: transfer to the zero address");
        require(
            value <= _balanceOf(from),
            "ERC20: transfer amount exceeds balance"
        );

        _setBalance(from, _balanceOf(from).sub(value));
        _setBalance(to, _balanceOf(to).add(value));
        emit Transfer(from, to, value);
    }

As you can see, USDT's transfer function includes a fee, while USDC's transfer function does not.

So this is the first place for you to investigate whether or not it might be causing the problem.

However, a much more critical aspect is the fact that USDT's transfer function does not return bool, as your contract function expects it to:

IERC20 token = IERC20(tokenAddress);
bool success = token.transfer(to, amount);

Now, this is a well known problem, of non-compliant ERC20 token contracts which were mostly deployed at an early phase of the ecosystem (mid-2017ish).

And apparently, USDT happens to be one of those tokens.

In order to handle this predicament, you can use OpenZeppelin's SafeERC20 Library, which allows interacting with ERC20 token contracts without having to take that non-compliance into account.

Unfortunately for you, since you've already deployed your contract, it might be a little too late.
You can either fix and redeploy it, or settle for the fact that you cannot use it for non-compliant tokens.


In this answer on ethereum.stackexchange, you can find a detailed description of:

  1. Calling a bool-returning function using an interface which declares it a bool-returning function
  2. Calling a none-returning function using an interface which declares it a bool-returning function
  3. Calling a bool-returning function using an interface which declares it a none-returning function
  4. Calling a none-returning function using an interface which declares it a none-returning function

TLDR, the results of the actions above are:

  1. Transaction completes successfully
  2. Transaction reverts with an error
  3. Transaction completes successfully
  4. Transaction completes successfully

And when your contract function takes the address of the USDT token contract as input, it essentially attempts to do #2 above, i.e., it attempts to call a function which returns nothing, using an interface which indicates that it returns bool.

1 Like

Thanks for the reply!!!

1 Like