The Consensys Smart Contract Best Practices guide recommends to prevent transferring tokens to the 0x0 address.

I understand that 80M or more is locked at this address, but so what? Why is that bad, it's the burn address right?

Where should we burn the tokens if not at 0x0?

  • 1
    The Consensys Smart Contract Best Practices - I disagree. The person who wrote the guide unlikely understood the all the implications. The answer below is good. Commented May 3, 2021 at 20:53

1 Answer 1


The ERC20 standard does not specify the mint and burn mechanisms, it is therefore up to the developer to define them.

The OpenZeppelin ERC20 reference implementation implements a burn function that decreases both the account balance and the token total supply :

function _burn(address account, uint256 amount) internal virtual {
    require(account != address(0), "ERC20: burn from the zero address");

    _beforeTokenTransfer(account, address(0), amount);

    uint256 accountBalance = _balances[account];
    require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
    _balances[account] = accountBalance - amount;
    _totalSupply -= amount;

    emit Transfer(account, address(0), amount);

The account balance and the total supply are respectively decremented with _balances[account] = accountBalance - amount; and _totalSupply -= amount;.

Although the event Transfer assimilates the burn operation to a transfer to the zero address, this is not the case, and this event is purely conventional.

This _burn function is internal and therefore can only be called within the smart contract and derived contracts. It is up to the developer to decide how to use this feature, if necessary. For example, to allow users to burn their token, you could create a public burn function wrapping the subfunction :

function burn(uint256 amount) public {
    _burn(msg.sender, amount)

Regarding the zero address, it is true that you can burn tokens by transferring them directly to it. However, the tokens will not be destroyed and the total supply will remain the same. So we can say that may be using the burn function is more appropriate, although no one can prevent a user from sending and forever locking tokens at addresses 0x0 (OpenZeppelin does for this one but this is not required by the standard) or 0x1 for example.

  • Thanks for the great answer @clement. While everything you explained makes total sense - you don't necessarily need to send tokens to the 0x0 if you don't care about changing the total supply, what if you do care and wish the total supply to stay fixed? And if there is also a solution to that, which circumvents sending tokens to the 0x0 address, why is it bad to send tokens to the 0x0 address? What harm are they trying to prevent by recommending not to send tokens to 0x0, or what's the advantages of not sending tokens to 0x0? Cheers! Commented May 3, 2021 at 21:40
  • well, it's pretty unlikely, but someone could someday figure out the private key to 0x0, and that would possibly have unintended consequence on your monetary supply. :) I'd say there is no good reason to send it to 0x0, and you can just handle it some other way instead.
    – Kyle Baker
    Commented Oct 31, 2021 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.