Make 0-valued transfers valid semantics (fire the event and return true)

EDIT: Replace “revert” with “returned false” in this issue; I realized StandardToken does not throw on error but then realized the issue is practically the same and still just as harmful

Reverting on 0-valued transfer and approval is an anti-pattern that pops up repeatedly in code reviews. I realized it’s because many people are copying your StandardToken.

These two lines should have && _value > 0 removed:

        if (balances[msg.sender] >= _value && _value > 0) {

        if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && _value > 0) {

0-valued transfers and approvals should be valid and behave almost like no-ops, without reverting state. This is so that consumer contracts do not have to take care to work around this edge case.

[simondlr]

Great points and well put @mbrock. Agreed.

Thanks for the comments/discussions.

Will change/fix soon.

[mbrock]

I also agree that it’s more parsimonious to have 0-valued transfers be harmless no-ops rather than failures.

It’s kind of like how append(x, []) is a harmless no-op rather than something which causes an EmptyAppendException.

From an algebraic perspective, zero being the identity for additive operations is an ancient and fundamental meme; returning an error on “addition by zero” is surprising and unusual.

We don’t yet know which contract will be the first to be surprised by this behavior. We’ve already seen some possible examples by @nmushegian.

For example a system that interacts with any number of external tokens and imposes some kind of configurable fees denominated in tokens. That fee is changed to 0 for some reason, which causes the contract to attempt to transfer 0 * x, which then fails unexpectedly, and now some user’s funds are locked.

That kind of problem seems much more serious than the risk of accidentally wasting a user’s gas because of a glitchy frontend. Such gas costs are a very limited risk, whereas the 0 fee example is an unbounded risk.

Someone could ask “why are you writing code that appends an empty string?”, and maybe the examples I came up with would sound contrived – but I still don’t want the string library to fail in such cases.