The ERC20 Token Standard is great, in that it allows wallets, exchanges, and client implementations to allow users to interface with a variety of tokens in a common way. But how can one of these clients verify that the underlying implementation of a token behind the interface actually conforms to the expectation defined by the standard?
For example, any contract that implements the ERC20 interface, could implement the transfer(address to, uint256 value) function to just ignore the to param and transfer to a hardcoded address.
I think that one solution is to verify that the token contract bytecode actually matches a reference implementation, and I believe this is what Consensys has done with their HumanStandardTokenFactory.sol example. This makes a lot of sense.
But when you look at examples that want to extend the functionality of a token, but still be treated with respect to the standard, like Beercoin (which is also awesome)…is the only way to verify that this the implementation conforms to the standard via social inspection and audit? Are wallet providers, exchanges, etc performing any other type of provable verification before granting something "token status", or just checking the box that they implemented the few interface functions?
Best Answer
I think it has to ultimately be human verification, unless it exactly matches an existing contract that's already been verified by humans. Even if all the functions that are supposed to be in the standard are there and do what they're supposed to, you can't be sure that somebody hasn't done something unexpected in a different part of the code.
It's probably not safe to rely on exchanges to add a given token to be auditing the contract code, although it would be certainly be good to have some kind of process for this.