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."
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!
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
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.
This contract is available on GitHub at: https://github.com/iRyanBell/vim20