Skip to content

Issues

Jump to bottom
Daejun Park edited this page Sep 14, 2018 · 8 revisions

Discrepancies between standard and reference implementation

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

Ambiguity in standard

Ambiguous "MAY" behaviors of authorizing (or revoking) an already authorized (or revoked, resp.) operator

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:

  1. always accept when a token holder attempts to authorize an already authorized operator.
  2. always revert when a token holder attempts to authorize an already authorized operator.
  3. randomly choose, either accept or revert, whenever a token holder attempts to re-authorize. (fully non-deterministic)
  4. always revert for some specific token holders attempting to re-authorize, but always allow for another specific token holder attempting to re-authorize.
  5. 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.

FIXED:

It turned out that the standard should have said like the following:

A token holder "MUST" authorize an already authorized operator.

A token holder "MUST" revoke an already revoked operator.

(i.e., MUST instead of MAY)

Ambiguous "SHOULD" behavior of sending to a regular address that doesn't register a ERC777TokensRecipient hook

Similarly, I have another question for the SHOULD behavior

In case of sending to a regular address that doesn't register a ERC777TokensRecipient hook, the nice table in (the end of) the standard says it "SHOULD accept", but it is not clear what it precisely means.

Below are possible interpretations:

  • It allows each implementation can choose a fixed behavior (either accept or revert) for all such cases.
  • Or, it allows each implementation can have a finer-controlled decision, e.g., accepting for some white-listed addresses, and/or reverting for some bad (or definitely-non-existing) addresses.
  • Or, it allows a even more sophisticated policy, e.g., accepting up to N times for some set of addresses, M times for another set of addresses, etc.
  • Or, extremely, it allows any arbitrary non-deterministic decision (e.g., decision by flipping a coin).

CLARIFIED:

It turned out that the standard allows the full non-deterministic behavior:

all of those scenario would be acceptable

Inconsistencies

  1. decimals()

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.

Clone this wiki locally