ERC20 Token Contract – Is the burnFrom Function Unsafe?

contract-designerc-20solidity

We have been issuing a token using a basic erc20 token contract from https://ethereum.org/token
An exchange that we wanted to list our token, asked for a collateral as they see the burnFrom() function could harm token owners.
Why would this function be harmful? You can only use this function when you got allowance from the wallet owner.
Plus, why is this code in the basic erc20 contract on the ethereum.org domain, if it is potentially harmful?

Does anyone has an answer to this question?

Best Answer

It's hard to say what someone else's concern could be without being in the room. I wonder if the "burn" talking-point is an example of more general concerns.

The linked code is a "minimal example" in a tutorial. It contains burn() and burnFrom() functions that are not part of the ERC20 standard. https://eips.ethereum.org/EIPS/eip-20. Those are both red flags for code that's supposed to be carefully constructed and well-understood.

Nothing in ERC20 forbids extension of the basic interface, so technically it is not a violation of the rules to add functions. If I were cross-examining your technical team, I would question why you need those functions to see if you have carefully considered answers, and if not, question why you have unnecessary code in your contract.

Exchanges have been burned by non-conforming ERC20 contracts that failed to observe subtleties in the spec. The README for the spec itself refers to two well-crafted implementations which begs the question: why are you using a minimal example from a tutorial?

It's not that it's a year old or using an old compiler, in my opinion. Afterall, bytecode is meant to work forever. However, since it is merely a tutorial, what assurances have you received that the code has been subjected to meticulous scrutiny? In the case that there is no assurance, no publicly available audit or quality assurance report, then have you engaged anyone to review it for you? You can see where that would be leading. What is your process, why is that way, how deep is the team's knowledge and why should we trust their thinking?

If you are presenting a copy/paste job from a tutorial and seem unaware of the possible implications, that speaks volumes about the potential for oversight in the token contract itself, and also in the broader scope of the contracts that use it. Tokens are generally useless unless coupled with a line-of-business app which will potentially have access to destructive processes that may or may not have a worthwhile purpose.

Exchanges are not in the quality-assurance business. It's not their job to review your code. It's your job to assure them that all risks are professionally and satisfactorily addressed.

Again, we may never know exactly what they are thinking. The foregoing is not meant to sound excessively critical. My intention is to convey some insight into how this may look from a risk-averse perspective.

Hope it helps.

Related Solutions

ERC-20 Allowance – Getting Allowance List After Approve Function in ERC-20

According to the ERC20 specification, whenever the approve() function is called, an Approval event needs to fire with the details of the approval:

Approval

MUST trigger on any successful call to approve(address _spender, uint256 _value).
event Approval(address indexed _owner, address indexed _spender, uint256 _value)

Thus if you want to know all of the approvals that have been made for a specific ERC20 token, you can look at the event logs for that contract filtering on the approvals.

You could similarly track the Transfer event to keep track of who has redeemed their allowances.

myContract.getPastEvents() should enable you to do both of these tasks with Web3.js v1.0.

Is that supported? If not, why is it not supported?

The ERC20 standard only defines a minimum interface required to meet the standard, and does not necessarily define the specific implementation of the standard. Some contract creators could absolutely add this functionality in addition to the other standard functions, but it would be an extra as it is not defined in the specification. Ultimately, holding and manipulating this data costs gas, and if you want to create a performant smart contract, you want to minimize extras like this as much as possible. In this situation, using the event log is a more cost effective alternative to storing this data on-chain.

Solidity 0.8.x – How to Increase Allowance of a Smart Contract to Transfer a User’s ERC20 Tokens

Are you talking about this contract?

https://rinkeby.etherscan.io/address/0x3b00ef435fa4fcff5c209a37d1f3dcff37c705ad#code

If so, I would personally just create my own interface, because the USDT implementation is kinda wild:

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IERC20 {
    function balanceOf(address owner) external view returns (uint256);

    function approve(address spender, uint256 value) external returns (bool);

    function allowance(address owner, address spender)
        external
        view
        returns (uint256);

    function increaseAllowance(address spender, uint256 addedValue)
        external
        returns (bool);

    function decreaseAllowance(address spender, uint256 subtractedValue)
        external
        returns (bool);
}

You can even delete the approve() function if you won't be using it.

Note that this will NOT work the same way on mainnet, because there's a completely different implementation of an older ERC20 version.

Best Answer

Related Solutions

ERC-20 Allowance – Getting Allowance List After Approve Function in ERC-20

Solidity 0.8.x – How to Increase Allowance of a Smart Contract to Transfer a User’s ERC20 Tokens

Related Topic