The ERC20 coin or token has, so far, been one of the really ‘killer’ features of ethereum. In less than a year ERC20 tokens have become the building block for numerous companies to start
- designing Dapp systems
- fuelled by their own economies
- paid for in their own tokens
- funded by Initial Coin Offerings
all thanks to the ethereum platform.
The effectiveness of the ERC20 specification has lead to these tokens easily being tradable on exchanges both centralised and decentralised and recognised by an increasing number of wallets with MetaMask being, at time of writing, the latest to support tokens.
The reason that ERC20 coins work is, of course, the standard interface plus the fact that (if you recall from Part II) that the interface functions and parameters are encoded in the Data part of the transaction.
From the ERC20 specifications, the most vital basic functions are :
function transfer(address _to, uint256 _value)
function balanceOf(address _owner) constant returns (uint256 balance)
From the ABI specifications, the complete function set would translate to
To transfer tokens we want the transfer function (a9059cbb) but we also need to know how many decimal places the coin uses.
The DDF token is a standard type token using 18 decimal places, just like ethereum does for ether, and can be found at address : 0xcc4ef9eeaf656ac1a2ab886743e98e97e090ed38
The details can be found on Etherscan.
Reading a balance
Since it does not cost anything to read a contract, you can check Alice’s account on Etherscan just by entering an address for the balanceOf function. You can also see how many tokens actually exist (totalSupply), the token’s name and symbol etc. Have a look if you haven’t done so.
Assume that we want to send 3 DDF Tokens to our lovely friend Alice from part 1 (remember Alice? It’s a blog about Alice!) we would encode the value 3 with 18 decimal places (3,000,000,000,000,000,000)
Then convert that to hex in 128 bits so 3 tokens becomes : 0x00000000000000000000000000000000000000000000000029A2241AF62C0000
I am sure that you all remember that Alice’s address is 0x31EFd75bc0b5fbafc6015Bd50590f4fDab6a3F22
Alice’s address expanded to 256 bit values is:
From the table above, the hash for the transfer function is
So, the whole data would be :
but keep the data on one line without a break (this was done for clarity).
Assuming that you have more than 3 DDF token in your wallet you can, by submitting these values to your multi-sig wallet send 3 DDF tokens to help dear Alice back out of the rabbit hole.
An ERC20 wallet has another useful feature : delegation using these calls.
In token crowd-sales, the token issuer may delegate the issuing of tokens to the crowd-sale contract. If they were to undertake a pre-sale for cash they could delegate the distribution of a certain number of tokens to the accountant.
Bob can delegate to Charlie the tight to issue 1,000 tokens on his behalf. To do so he would use the approve function.
Charlie can now dish out Bob’s tokens as he sees fit up to a maximum of 1000 tokens. e.g.
transferFrom(<Bob's address>,<alice's address>,10000000000000000000)
If Bob changes his mind, he can revoke the decision by approving Charlie to spend Zero tokens but he cannot recover any tokens that Charlie has already allocated.
Wrapping it up
In this article I have tried to cover two bases, explaining a bit about how you control a token works by calling its functions and also how you can control those functions from a multi-sig wallet. In the light of recent ICO activity with crowd-sales raising tens or even hundreds of millions of dollars, these tokens certainly have real value so you may well want to use a multi-sig wallet to control them.
Any comments gladly listened to, Alice is always happy to receive any fractions of Ether that fall off the end of your wallet. Thanks to those great guys at EtherScan you can find her wallet address as DaveApp(Alice)!
Part III — ERC20 tokens and the multi-sig wallet