ERC-223: problematic description of tokenReceived

[u59149403]

Pull Request

3344c58

What happened?

In ERC-223 tokenReceived's description reads: "It works by analogy with the fallback function of Ether transactions and returns nothing". But then: "The tokenReceived function must return 0x8943ec02 after handling an incoming token transfer. The tokenReceived function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02)".

First, this is not clear what "may not return the magic value 0x8943ec02" means. It may mean that implementations of tokenReceived are allowed to return something other than 0x8943ec02 and this will be okay. And it may mean something completely opposite: that failback function can return something other than 0x8943ec02 and for this reason we mandate tokenReceived to return 0x8943ec02 to distinguish true tokenReceived from failback function.

I'm nearly sure that the second interpretation was intended. So, please, rephrase somehow this paragraph. Ideally, this sentence about failback function should be moved to rationale.

Also, we see phrase "It works by analogy with the fallback function of Ether transactions and returns nothing". Part "returns nothing" is wrong. It returns 0x8943ec02, not nothing.

Then: we see phrase "This function can be manually called by a EOA" here. What this means? That EOAs are allowed to call tokenReceived and tokenReceived should successfully handle this? Or opposite: tokenReceived implementations should beware that EOAs may call tokenReceived and thus should reject this? I suggest simply remove this phrase, because it adds nothing.

ping @Dexaran .

Also, I think I found some other problems in ERC-223, but I didn't write them down, so I don't remember them. If you want, I can re-read ERC-223 and possibly report additional problems

Relevant log output

No response

[u59149403]

Also:

ERC-20 deposit: approve ~46 gas, transferFrom ~75K gas

I think you meant 46K gas, not 46

[Dexaran]

I think you meant 46K gas, not 46

Yes, must be 46K.

Then: we see phrase "This function can be manually called by a EOA" here. What this means?

This is more of a security consideration to make it clear that if the tokenReceived function was invoked - it does not automatically mean that some token was deposited. A user could call it from a EOA.

Honestly this function can be called from a contract which is not a ERC-223 token, so it would be better to add that description as well.

We need to warn the implementers that the fact of tokenReceived function call does not automatically mean that tokens were deposited and they need to check that.

It works by analogy with the fallback function of Ether transactions and returns nothing

Yes, the "and returns nothing" is simply incorrect. In the old days of the standard implementation it indeed was returning nothing, but that was changed at some point and the description text was simply not updated. Needs a fix.

we mandate tokenReceived to return 0x8943ec02 to distinguish true tokenReceived from failback function.

This.

can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02)

The word "may" was used because its possible to assemble a return value within fallback function by pushing something onto stack at the memory position where the returned value is expected to be stored, I'm pretty sure it was possible in solidity before 0.4.0 but that needs to be checked. The functon tokenReceived MUST return the magic value.

The implementer CAN check if the function call was handled by the tokenReceived or fallback by verifying if the returned value is magic value or not.

[github-actions]

There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity.

[u59149403]

ping

[Rafazzzz]

k

[skidipapo]

#719

[h4wk77]

Pull Request

3344c58

What happened?

In ERC-223 tokenReceived's description reads: "It works by analogy with the fallback function of Ether transactions and returns nothing". But then: "The tokenReceived function must return 0x8943ec02 after handling an incoming token transfer. The tokenReceived function call can be handled by the fallback function of the recipient contact (and in this case it may not return the magic value 0x8943ec02)".

First, this is not clear what "may not return the magic value 0x8943ec02" means. It may mean that implementations of tokenReceived are allowed to return something other than 0x8943ec02 and this will be okay. And it may mean something completely opposite: that failback function can return something other than 0x8943ec02 and for this reason we mandate tokenReceived to return 0x8943ec02 to distinguish true tokenReceived from failback function.

I'm nearly sure that the second interpretation was intended. So, please, rephrase somehow this paragraph. Ideally, this sentence about failback function should be moved to rationale.

Also, we see phrase "It works by analogy with the fallback function of Ether transactions and returns nothing". Part "returns nothing" is wrong. It returns 0x8943ec02, not nothing.

Then: we see phrase "This function can be manually called by a EOA" here. What this means? That EOAs are allowed to call tokenReceived and tokenReceived should successfully handle this? Or opposite: tokenReceived implementations should beware that EOAs may call tokenReceived and thus should reject this? I suggest simply remove this phrase, because it adds nothing.

ping @Dexaran .

Also, I think I found some other problems in ERC-223, but I didn't write them down, so I don't remember them. If you want, I can re-read ERC-223 and possibly report additional problems

Relevant log output

No response

Regarding your points:

tokenReceived return value and fallback function ambiguity:
You've highlighted a crucial ambiguity. The intention behind ERC-223 was that the tokenReceived function, when called by the token contract during a transfer, must return the specific magic value 0x8943ec02. This specific return value is designed to differentiate a proper tokenReceived invocation from a generic fallback function. The fallback function of the recipient contract may also be designed to handle token transfers, but it is not guaranteed to return the 0x8943ec02 value, and its behavior should not be relied upon to match tokenReceived. Your interpretation that the magic value is essential for distinguishing a true tokenReceived call from a generic fallback call is likely correct.
I agree that moving the explanation regarding the fallback function's potential deviation from returning the magic value to the "Rationale" section would significantly improve clarity.

"returns nothing" inaccuracy:
You are absolutely right. The phrase "returns nothing" in the description is misleading, as the function is indeed expected to return the magic value 0x8943ec02 upon successful handling of an incoming token transfer. This should be corrected in the description to accurately reflect the expected behavior.

Ambiguity of "This function can be manually called by a EOA":
This sentence indeed creates ambiguity. The primary interaction flow for ERC-223 transfers involves the token contract invoking tokenReceived on the recipient contract. While a recipient contract's tokenReceived function might be designed to be called directly by an EOA (or another contract) for specific purposes, this is not the core mechanism of token transfers from the token contract's perspective. Given the confusion it causes, removing it entirely or rephrasing it to clarify that the recipient contract's logic is invoked would be beneficial. Removing it might be the cleanest solution to avoid misinterpretation.

Offer for further issues:
We greatly appreciate your willingness to re-read ERC-223 and report any other problems or suggestions. This kind of detailed, critical review is essential for improving the standard. Please feel free to open new issues or comment here with any further findings you might have.

[github-actions]

There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity.