Token Implementation Best Practice

Last checked: 20 August 2021. Remember to check the Github page for any updates to this section.

Implementing Tokens should comply with other best practices, but also have some unique considerations.

Comply with the latest standard

Generally speaking, smart contracts of tokens should follow an accepted and stable standard.

Examples of currently accepted standards include:

Be aware of front running attacks on EIP-20

The EIP-20 token's approve() function creates the potential for an approved spender to spend more than the intended amount. A front running attack can be used, enabling an approved spender to call transferFrom() both before and after the call to approve() is processed. More details are available on the EIP, and in this document.

Prevent transferring tokens to the 0x0 address

At the time of writing, the "zero" address (0x0000000000000000000000000000000000000000) holds tokens with a value of more than 80$ million.

Prevent transferring tokens to the contract address

Consider also preventing the transfer of tokens to the same address of the smart contract.

An example of the potential for loss by leaving this open is the EOS token smart contract where more than 90,000 tokens are stuck at the contract address.

Example

An example of implementing both the above recommendations would be to create the following modifier; validating that the "to" address is neither 0x0 nor the smart contract's own address:

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

The modifier should then be applied to the "transfer" and "transferFrom" methods:

    function transfer(address _to, uint _value)
        validDestination(_to)
        returns (bool) 
    {
        (... your logic ...)
    }

    function transferFrom(address _from, address _to, uint _value)
        validDestination(_to)
        returns (bool) 
    {
        (... your logic ...)
    }

Last updated