ERC-20 – Does Ethereum Wallet/Mist Multisig Wallet Support ERC20 Tokens?

Smart contracts expose multiple functions as a public API. In general, to interact with any contract, its ABI (different from API) must be used to properly encode/decode messages to/from a contract. This is true regardless of function or event.

The Mist multisig wallet is based on the code at https://raw.githubusercontent.com/ethereum/dapp-bin/master/wallet/wallet.sol. However, this makes use of many Solidity language features, so understanding it is not as straightforward as reading a single contract's code.

Mist exposes most of the contract functionality via an HTML interface embedded in the application. If you want to arbitrarily interact with functions not provided in the default interface, you can use web3.js or some other high-level tool.

At a high level, the main parts of ERC20 specify:

1. how tokens can be transferred by its owner

2. how tokens can be transferred on behalf of an owner

3. how to get data about the token

4. events about the token

The first specifies the obvious requirement that tokens must be transferrable, and what ERC20 defines is that you would tell the token contract to transfer some number of your tokens to someone else. You would not tell a token contract to "send" or "give" tokens to someone else: the term ERC20 chose is transfer.

The second part allows you to approve someone to take some number of your tokens and transferFrom you to someone else. It's less obvious why that's needed but it helps in some workflows. For example, one goal of Ethereum and smart contracts is "veridical computing" and a way for this to happen is for someone to publish their contract which says: "if you approve me to use some of your tokens, I will give you X". X could be another token or "smart property". Now you can read that contract, approve the contract and execute the contract. As part of the contract execution, it will transferFrom your tokens and deliver you X. If the contract did not have those terms, you had full control to not approve and execute it in the first place.

This is different from giving the contract your tokens first, and then asking it to deliver X. You don't give someone something and then ask them to sign a promise to deliver you X, because they might take your tokens and ignore your request for X. (There's ways that the contract can be made to keep its promise, but the workflow could be more complicated.) You can see that the type of contract by me "If you give me T, I will give you X" is simpler than you writing a contract for "I will give you T, but you must then give me X": the former is a promise by me and your choice to accept or not; the latter is written by you and I need to accept first before you do anything.

If you approve someone, you or they can find out for how many tokens, by checking their allowance.

The other parts of ERC20 allows anyone to get data like the name, symbol, totalSupply of tokens, as well as the balanceOf an account.

Finally, ERC20 specifies the format and meaning of certain events, for example a Transfer must indicate firstly the sender, secondly the recipient, and thirdly the number of tokens. User interfaces can then take comfort that what they display to users will make sense for tokens that comply with ERC20.

The finalized ERC20 is at https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md