Issues

Discrepancies between standard and reference implementation

We found some discrepancies between the current standard and the reference implementation:

The standard says:

A token holder MAY authorize an already authorized operator.

A token holder MAY revoke an already revoked operator.

The term "MAY" is ambiguous. Below is the list of some possible interpretations of the term, which we asked the developers to confirm:

A standard-conforming token implementation can:

always accept when a token holder attempts to authorize an already authorized operator.
always revert when a token holder attempts to authorize an already authorized operator.
randomly choose, either accept or revert, whenever a token holder attempts to re-authorize. (fully non-deterministic)
always revert for some specific token holders attempting to re-authorize, but always allow for another specific token holder attempting to re-authorize.
or more chaotic way of deciding whether to accept or revert. (here "chaotic" means some combination of deterministic and non-deterministic choices, like (3), which is different to the fully non-deterministic choice, like (2).)

Probably, we guess they may intend either:

allow the fully non-deterministic decision, or
let them choose either (0) or (1), in advance, and keep the same decision throughout the token contract lifetime.

Hence for compatibility reasons, decimals MUST be implemented for ERC20 compatible tokens.

vs

The token MAY implement decimals() for backward compatibility with ERC20. If implemented, it MUST always return 18.