I found an ERC20Basic interface floating around which closer matches what I wanted to implement for a token as I'd prefer to not have support for approve and transferFrom. What are the implications of implementing https://github.com/ethereum/EIPs/issues/179 instead of the standard ERC20 interface?
Consider:
- How it shows up in Etherscan and others explorers and tools.
- Issues with exchanges?
- Any good reasons for that functionality that I haven't thought of?
Also, if I have all of the functions from the ERC20 interface and just put revert() for the allowance-related ones, am I gaining anything over just not having them there at all?
I figure this question is complicated because it depends on how the most popular users of the Ethereum block chain are programmed. For instance, I would want to play nice with Etherscan to have everything showing up correctly and also not be turned down by exchanges for a preventable technical reason.
Best Answer
The ERC20 has been accepted as a standard, wallets and explorer will use that specification as a base to implement their functionality.
It is not perfect but it is widely used. IMHO it is better to be compatible with most applications. It is within the standard to return false for those methods that return a bool with the result of the operation, or zero for
allowance.