Never cause investors to lose money: Prevent transferring Ethereum Tokens to 0x0 and your contract address

This was contributed to ConsenSys repository for Smart Contract Best Practices at GitHub. My edits were merged, after deleting some sentences and paraphrasing some others while keeping the idea and the suggested code: https://github.com/ConsenSys/smart-contract-best-practices/pull/143. Accordingly, I rote Safe ERC20: https://github.com/ConsenSys/Tokens/pull/120

Prevent transferring to the 0x0 address

If you allow human mistakes, it will happen. By the time of writing this document, the address 0x0000000000000000000000000000000000000000 contains tokens with a value of more than 80$ millions (at that moment; And it is still increasing). And it is still increasing. You can see there are many stuck Tokens, for example: AMIS, Arcade, LAToken and many others. Just because of small oversight.

However, as you can see, there are also more than 7 thousands Ether at the 0x0 address. But, Ether could be easily resend back to its original addresses with a special or the next hard-fork. Whereas, sending the tokens back to their rightful owners will be the responsibility of the token’s developers. And it will depend if the token is mintable or not. Proactive prevention strategies can help preventing this from happening. And it will cost developers and operation officers less headache later.

Prevent transferring to the contract address

Another human mistake that Smart Contract should prevent is the transfer to the same address of the Smart Contract. To see an example of how this could be harmful to the community, you can check that lots of EOS Tokens (more than 90,000) are just stuck at the contract address. However, those locked EOS tokens will be claimed once the network is lunched according to their support.

Sample Code

To see a good example of implementing both: Preventing transfer to the 0x0 address and Preventing transfer to the contract address, you can check the Smart Contract of Kyber Network Crystal token. It is implemented using a modifier validating that the “to” address is not 0x0:

modifier validDestination( address to ) {
    require(to != address(0x0));
    require(to != address(this) );
    _;
}

And the modifier should be applied on both “transfer” and “transferFrom” methods. The following is an example:

function transfer(address _to, uint _value)
    [other modifiers]
    validDestination(_to)
    returns (bool) {
    (... your logic ...)
}
function transferFrom(address _from, address _to, uint _value)
    [other modifiers]
    validDestination(_to)
    returns (bool) {
    (... your logic ...)
}

Another good examples of Tokens that prevent transferring to 0x0 address as well as the transfer to the Smart Contract address are: Status Network Token (SNT), Cindicator (CND) and Bounty0x Token. Their code is not as clean as Kyber Network Crystals. Yet it will do the job. They all use the following code snippet:

// Do not allow transfer to 0x0 or the token contract itself
if ((_to == 0) || (_to == address(this))) throw;

To reference an example of an ERC 20 token that is mintable and have fair complexity, but yet did not consider the above mentioned, you can see LAToken.

Note: This publication is a modified copy of: https://github.com/Muhammad-Altabba/smart-contract-best-practices/blob/master/docs/tokens.md

You may like to check the following publication for a wider view angle: Hundreds of Millions of Dollars Locked at Ethereum 0x0 Address and Smart Contracts’ Addresses — How, Why and What to do?