Solidity Contract Development – How to Determine ERC20 Compliance

contract-developmenterc-20solidity

How is it exactly determined whether a contract is ERC20 compliant and who determines it? After reading Do I have to implement ERC20 signature as separate contract and use inheritance? and some googling, I have some ideas.

1) Who decides whether a contract is ERC20 compliant? Is it just the one who wants to use it (exchange, wallet, …)?

2) How do you determine whether a contract is ERC20 compliant? My current understanding is that all you need is to have the right function signatures (right function hashes). So it doesn't exactly have to inherit (implement) from an ERC20 interface. Is that correct?

3) If the answer to the second question is "yes", is it ok to add for example payable modifier to some of the functions (as I've understood, it wouldn't change the hash of the function)?

If the answer to question 2 and 3 is "yes", then the following would be a valid implementation of ERC20 standard (assuming the rest of the functions are implemented also):

contract A {
  ...
  function transfer(address to, uint tokens) public payable returns (bool success) {
    ...
  }
  ...
}

Best Answer

There wasn't a standard to determine if a contract support an interface at the time ERC20 was conceived (*).

Some block explorers and wallets can make verifications, for example for a ERC20 contracts they can verify if the public functions are available and return something useful, ie symbol, name, decimals, etc.

A block explorer that support contract verification can check the ABI for other methods to also be present, ie transfer, approve, etc.

That obviously is not enough, a contract that always throws, return false, or zero (depending on the function) can still comply with the EIP20 standard.

(*) There's now EIP 165 that allows to query a contract for supported interfaces.

Related Topic