Creating a Utility Token for VIM Network |

Creating a Utility Token for VIM Network

March 01, 2019

VIM Network Utility

The ERC20 token specification is an early cryptocurrency tokenization standard for the Ethereum network. It outlines a small collection of core smart contract functions as defined by the associated Ethereum Request For Comments (ERC) identifier thread.

“These ERC discussion threads essentially serve as a peer review process for the exploration and implementation details for solving real world blockchain-related software development and mechanism design problems in an open democratic forum.”

The ERC20 token specification:


  • Transfer(address indexed _from, address indexed _to, uint256 _value)
  • Approval(address indexed _owner, address indexed _spender, uint256 _value)


  • totalSupply() public view returns (uint256 totalSupply)
  • balanceOf(address _owner) public view returns (uint256 balance)
  • transfer(address _to, uint256 _value) public returns (bool success)
  • transferFrom(address _from, address _to, uint256 _value) public returns (bool success
  • approve(address _spender, uint256 _value) public returns (bool success)
  • allowance(address _owner, address _spender) public view returns (uint256 remaining)

A standard ERC20 token is just a starting point.

With just this minimal suite of methods, an Ethereum smart contract can behave as its own cryptocurrency token. These getter and setter functions provide a standard interface for the public to access ledger balances and interact with the contract’s transfer functions. The ERC20 token also includes an allowance function to appropriate funds to a designated spender address.

Implementing these functions securely, however, can be challenging. That’s where OpenZeppelin comes in to help pull this off!

The fastest way to begin experimenting:

Now, after getting my first ERC20 token deployed onto a testnet server, I soon ran into an issue with my smart contract payment mechanism.

When an ERC20 token is sent to a smart contract address rather than an individual’s address, the internal ledger within the token contract itself updates to reflect the transfer, but the receiving contract on the other end does not receive any sort of notification event from the token. To facilitate eventful individual -> smart contract transfers and smart contract -> smart contract transfers, the public transfer functions need to be rewritten through an override method to communicate directly with the receiving contract. (This functionality is currently being discussed under ERC223.)

I added an ERC223-spec tokenFallback() Token Receiver function and rewrote the transfer methods using an override, then built a small migration script for Truffle with a construction wrapper used to mint a fixed supply of this custom cryptocurrency token and deploy it to the network.

I reached out to the team at OpenZeppelin to see if I could grab some feedback on my implementation. The team suggested using the super keyword rather than interacting with the _transfer() method directly and adding support for the transferFrom() method.

During a testing process with this new contract, I noticed that tokens could be lost to ill-equipped smart contracts lacking a tokenFallback() implementation. I added a return value to the fallback mechanism to provide a sort of handshake between the two smart contract parties. With a return value check now added to this transfer override, only receiving contracts which have completed successfully validate to finalize the transfer.