Have you considered allowing this feature set by extending ERC20 with approveAndCall? Inside the "charging" contract you'll have one function call in any case (in this case transferFrom), but on the caller side entering is now an atomic operation, similar to transferToContract

The main goals of my proposal were:

1. Prevent accidentally sent tokens from being held by contract.
2. Allow users to deposit their tokens in contract the way simple as ether by a single transaction (i.e. transferToContract( ) call) with no need to call approval than call transferFrom.
3. Make token transactions behave same as Ether transactions.

approveAndCall assumes that target contract will call transferFrom and its not like Ether transactions do. There is no need to allow target contract to withdraw tokens from someone (tx initiator). There is no need to fire Approval event also. From a logical point of view, we should just notify target contract that transaction appears. Also fire Transfer event with no approvals.

Updated my ERC23 token code with a function assembling receiver address to ensure token contract if the receiver is a contract or an address.

Ok I think I see where you are coming from...

What about, devs generally seem to want to replace the "execute on transfer" for ETH with a hard coded token interface with no execute on transfer, potentially just ERC20?

Is this a bad side effect or a naturally good thing? Doesn't exec-on-transfer make the simplest use cases more complex and maybe more dangerous, while not allowing anything really new?

exec-on-transfer make the simplest use cases more complex and maybe more dangerous

for contract developers you mean. From users point of view we just need to call 'transfer token' on MEW or transfer directly in contract and dont care any more about what is going on instead of calling approval then calling deposit or something like this with a chance of mistake that will cause a loss of tokens.

for contract developers you mean. From users point of view we just need to call 'transfer token' on MEW or transfer directly in contract and dont care any more about what is going on instead of calling approval then calling deposit or something like this with a chance of mistake that will cause a loss of tokens.

Contract devs are not being unsympathetic to user experience by nitpicking the semantics of contract code... I understand that approve + doSomething is not optimal UX, but these are things you can abstract away at the user interface level, and this abstraction honestly has very few side effects, while making composing contracts more safe ("what stuff could happen if I transfer this token here?")

(personally I think the real base abstraction is a binary per-address approve but that is another side thread)

Well designed token contract assumes you need to trust only contract and ethereum EVM. UI level abstraction assumes you need to trust UI developers. It also requires some things to be done by UI devs. I dont see any abstraction that is required already done. So what reason is to make a lot of requirements and dependencies between contract developers,UI developers and users when there is a way to avoid it.
At the other hand the main problem of every cryptocurrency is network bandwidth right now. Transferring of ERC20 token to the contract is a couple of two different transactions in fact. While transferring ERC23 token to a contract is a single transaction.
ERC20 transfer to contract also fires Approval event then fires Transfer event. Such irrational use of blockchain can cause extra bloating. ERC23 transfer fires only Transfer event.

We were thinking about doing a similar proposal from Aragon while working on economic abstraction for companies. We finally decided approve and transferFrom was a simpler interface and more secure.

Simpler and more secure? What reasons do you have thinking so? I named my reasons.
Easier usage. Better optimization. Less requirements.

In the current implementation, if a contract doesn't implement the receiver protocol, the transfer of tokens to an address that happens to be a contract will throw https://github.com/Dexaran/ERC23-tokens/blob/master/ERC23_token.sol#L56

Also I see the problem that the receiver needs to keep a list of what tokens it supports.

Also I didn't know about approveAndCall, but it seems the way to go for me.

My two cents, I would be happy to see approveAndCall be part of the standard, but your current solution, while cool, I think it would bring too much overhead to an already very simple and versatile protocol.

There could be a standard to approveAndCall data payload that calls the similar to your so called fallback in your proposal, and the this fallback doing some delegatecall magic could actually call a function in the contract passing the sender and the value as function params. In the fallback function you could do your token accounting and then call whatever function the caller wanted.

Sorry for the ramblings, I think I will actually come up with a parallel proposal for this.

In the current implementation, if a contract doesn't implement the receiver protocol, the transfer of tokens to an address that happens to be a contract will throw

As I said earlier it's done to prevent accidentally transactions of tokens to contract address where tokens will not be accessible any more.
Contracts are throwing accidentally ether transactions if no fallback payable function is implemented. The same mechanism for accidentally token transactions not exists so Im suggesting to implement it now.

Also I didn't know about approveAndCall, but it seems the way to go for me.

approveAndCall may be a good thing or may be not but now it is not implemented in ERC20 and will not solve accidentally token transactions between address and contract so Im not suggesting to implement approveAndCall.

My proposal solves a number of problems:

1. Accidentally transactions between address and contract that is not supporting this token will no longer cause a loss of tokens.
2. For users: Allows not to care about contract logic of work. To transfer tokens wherever you want, you always need to call only the transfer function.
3. For contract developers: Allows to handle incoming token transactions similar to incoming ether transaction.
4. It also optimizes blockchain usage.

If you found my proposal too complex to accept, then I found this increase in complexity a reasonable price, which should be paid for preventing accidental loss of tokens in the entire future.

Also I see the problem that the receiver needs to keep a list of what tokens it supports.

I don't see it is a problem but if this is the only thing that prevents the token standard from being accepted I designed a light version of contract-receiver. It will accept every incoming ERC23 token and do nothing with it. It can be called "token-trap" contract.
You can browse it here: https://github.com/Dexaran/ERC23-tokens/tree/light_version

I do like it, in fact i would also suggest for wallet contracts that the fallback func fires an standard event on the receiving contract called TokenTransfer(address _from, uint _value)
Tho i would rename the fallback func to t(...) or tokenFallback(...), sounds better.

@Dexaran those are all good points indeed. Sorry if the feedback seemed harsh, I'm indeed really interested in getting closer to economic abstraction so contracts can operate with tokens in a similar way the can with ether.

What do you think about the fallback function being something liket(address tokenSender, uint value, bytes data) and then the fallback function can do a delegatecall to itself with this data to simulate a payable function?

How you mean simulate a payable function?

Btw i don't fully understand why a contract should add supported tokens? As long as a contract fires the fallback function, it will be ERC 20 + 23

Btw i don't fully understand why a contract should add supported tokens?

Contract that is working with a specified tokens may contrain a mapping of supported tokens.For example if we are working with only Unicorns and incoming Token123 transaction appears we should reject transaction of not supported Token123.
Supported token may also be hardcoded or set inside receiving contract in any way you prefer. I just recommended addToken and removeToken functions to be in contract but they are not required.

Im not sure if i would make that into the standard, i find the fallback function useful, but as long as they are ERC 20 the contract should be able to deal with it. If he wants to reject certain tokens, than thats something they can do, but it doesn't need to be part of this standard.

By simulate a payable function I mean that after the token fallback is called, a specific function in the contract is called.

A rough, pseudo-Solidity implementation would be:

contract TokenReceiver {
  function t(address tokenSender, uint value, bytes payload) {
     if (_data) {
         delegatecall(this, payload)
     }
  }

  function foo() {}
}

So you could do transfer(contractAddress, value, '0xc2985578') in the token and have it call the function foo() in the receiving contract by sending value with a token. Maybe a couple of parameters should be added to the foo() like functions so they get the sender and the amount of tokens received.

The only thing that would need to be included in the standard is the case in which transfer has a payload parameter, as the way you handle it in the fallback could be up to every contract to decide how to do it.

Also regarding supported tokens, I think if a specific contract wants to only support a set of tokens or blacklist a specific one they can do it as part of their implementation, but I support the idea @that it shouldn't be included in the standard.

@frozeman I would recommend to "reject everything that is not marked as supported" but not "accept everything that is not marked to be rejected" because of when contract like the dao-refund is written it shouldn't accept any of incoming token except DAO. If DAO-token is not ERC23 so there is no way to accept anything ERC23 and we should place function tokenFallback(address _from, uint _amount) { throw; } inside dao-refund to make every ERC23 be rejected.
But if we need to make a DAO23 refund contract to accept ERC23 standard based tokens (DAO23) we should specify DAO23 as allowed. So any other ERC23 token will still be rejected.
Token standard is a recomendation to token developers how to develop their tokens in the best way. So I found it important not only recommend how tokens should be developed but also how token transactions should be handled.
Do you think it is not needed to be included in token standard?

What do you think about the fallback function being something liket(address tokenSender, uint value, bytes data)

@izqui as I understand it you are recommending to make token transactions behaving one step more similar to Ether transactions.
Where t(address tokenSender, uint value, bytes payload) means
address tokenSender == msg.sender
uint value == msg.value
bytes payload == msg.data

Exactly. And the actual msg.sender of t(...) is the token being used to transfer value.

So extending your comparison you would have:

address tokenSender == msg.sender
uint value == msg.value
bytes payload == msg.data
msg.sender == ether

Of course. tx.origin is now an address who is sending tokens, msg.sender is contract of sent token, msg.data is data signifying what function to call inside the token contract and payload is data signifying what function to call inside contract-reveiver of tokens.
Also tokenSender is address who is sending tokens too when only contract of tokens and contract-receiver are involved and no other contracts are called.
I found it awesome idea but I need to do some tests. So I cant say anything more specific right now.

Something to keep in mind regarding tx.origin is that in the case of usingtransferFrom(), tx.origin will be the authorized address to make the transaction and not the former token owner, which tbh I'm not really sure which one of the two should be accounted as the sender in this case.

I see we are 1 step away from creating Token-based Ethereum inside Ether-based Ethereum.
According to your idea token fallback function should handle incoming token transactions only in this manner:

function tokenFallback(address _from, uint _value, bytes payload){
  if(_data){
    delegatecall(this, payload);
   } else {
    //tokenFallback code here
  }
}

Because of Ether fallback function handles only transactions of value (ETH).
And as @frozeman said its not a part of token standard already. I found your idea cool but as for me I dont really know. So I want to get more feedback and do some more tests.
And of course there is always a possability just to ignore incoming data and handle only _from and _value as I suggested earlier.

I decided that token transaction must contain bytes data.

It's not a solution of any of the problems I'm aiming to solve but it may be needed for future use. As long as there is a way to attach data to Ether transactions I think there should be a way to do the same with token transactions too.
I don't care how exactly this will be used to attach HEX messages to token transactions or to encode inner functions execution but the way to attach data to the transaction (token or Ether) must exist.
As the result of this transfer function is changed and now contains bytes _data.

In solidity version 0.6.0+ a special receive() function was introduced to handle plain Ether transfers.

To keep the behavior of standard ERC223 tokens intuitive and similar to Ether behavior I would rename the tokenFallback(address, uint256, bytes calldata) function to tokenReceived(address, uint256, bytes calldata)

I would suggest upgrading ERC223 token contracts to work with a new tokenReceived function.

If there are any contracts that must ensure workflow with both the "old" tokens and the updated ones then I would suggest the following workaround:

contract ReceiverTest {
    
    function tokenReceived(address _from, uint256 _amount, bytes calldata _data) public
    {
        // ACTUAL CODE HERE
    }
    
    function tokenFallback(address _from, uint256 _amount, bytes calldata _data) public
    {
        tokenReceived(_from, _amount, _data);
    }
    
}

New getter function standard() added:

standard

function standard() constant returns (string _standard)

Get the standard of token contract. For some services it is important to know how to treat this particular token. If token supports ERC223 standard then it must explicitly tell that it does.

This function MUST return "erc223" for this token standard. If no "standard()" function is implemented in the contract then the contract must be considered to be ERC20.

At this point it may be important to differentiate token standards. The easiest way so far is to make sure that contract explicitly tells which standard it supports.

I don't think that pseudointrospection or other methods are efficient just because these can not describe any internal logic of token behavior (which is important for ERC223 / ERC20 differentiation because their APIs are similar).

function standard() constant returns (string _standard)

Shouldn't this return a list of strings? Tokens could easily implement multiple standards, as long as the standards don't conflict.

But also, what happens if a token declares that it implements a standard, but the implemented interfaces don't actually conform? The interface has to be checked for conformance with given standards anyway by potential callers. So I don't know if declaring the standard in this way is super helpful from an implemented interface point of view.

Although maybe it is still useful from a semantic point of view? It's possible for a contract to conform to an interface but have different behavior from the standard.

Shouldn't this return a list of strings? Tokens could easily implement multiple standards, as long as the standards don't conflict.

You are probably correct.
However I've never seen other token standards strictly declaring themselves through any functions. In most cases pseudo-introspection is being used. As the result I would just introduce a special function distinct to ERC223 standard that would tell UIs that a token supports this standard (because pseudo-introspection does not work here since transfer functions of ERC20 and ERC223 have the same signature).

But also, what happens if a token declares that it implements a standard, but the implemented interfaces don't actually conform?

Well, that would be developer's mistake. As the result their token will not work as intended with some UIs that rely on this feature. For example if one wallet allows sending ERC20 transfers and ERC223 transfers with data and a user wants to send a token that declares itself as erc223-compatible then this transaction would fail if that token does not in fact implement transfer(address,uint256,bytes) function

So I don't know if declaring the standard in this way is super helpful from an implemented interface point of view.

I'm currently engaged in a wallet development that supports automated token adding. This wallet allows two types of different transactions - simple ERC20-like transfer and ERC223-like transfer with data.

A user should simply feed it contracts address to add a token to "his account". However the problem is that we don't know which standard this token supports and there is no way to know this automatically - both standards have similar function signatures, also without reviewing the code you can't know if it supports transfer with data or not.

UI fetches some implementation-specific details from the contract directly - name, symbol and decimals. It can similarly determine whether to allow user sending data or not by checking if token has this specific function "standard()" that is only part of ERC223 but not ERC20.

It's possible for a contract to conform to an interface but have different behavior from the standard.

Yes it is possible. However the point of the standard is that you are automatically supported by a wide variety of tools (UIs, wallets, explorers etc) but if you declare that you conform to some standard while in fact you do not - then you can get errors on the side of all these UIs, wallets and explorers that expect you to behave as if you would be compliant with the standard you declared.

As the result I would just introduce a special function distinct to ERC223 standard that would tell UIs that a token supports this standard

Then it should probably be named implementsERC223() (returning a Boolean) or something specific to this one standard.

We're going to start running into naming conflicts given that there are no namespaces in Ethereum contracts.

(because pseudo-introspection does not work here since transfer functions of ERC20 and ERC223 have the same signature).

You can't decide what interface is implemented by looking at only one method when determining conformance with introspection. You need to check whether all methods in a given interface are implemented.

this transaction would fail if that token does not in fact implement transfer(address,uint256,bytes) function

Since ERC20 is so common now, wouldn't it be better to name this function transfer_with_data or something, so that a contract could implement both ERC20 and ERC223?

Then it should probably be named implementsERC223() (returning a Boolean) or something specific to this one standard.

There can be some UIs that deal with different tokens differently even though these are still "tokens"from user's point of view. For example an UI that supports ERC20, ERC223 and NFTs would display them differently:

• for ERC20 it would display the balance and allow transfers / approvals
• for ERC223 it would display the balance and allow transfers / transfers with data encoded
• for NFTs it would display number of NFTs of that type owned by user's address and display each NFT separately

I guess that it would be much easier for that type of UI if there is a special function standard() that tells what type of standard the token supports.

If some token supports multiple standards then it could return "erc223,erc20"

Since ERC20 is so common now, wouldn't it be better to name this function transfer_with_data or something, so that a contract could implement both ERC20 and ERC223?

I don't see any benefit in renaming this. Anyways ERC223 has two standard transfer function (one similar to ERC20 transfer and the other one with _data).

It doesn't introduce any benefit renaming transfer(address, uint256, bytes) to transfer_with_data(address, uint256, bytes) - both functions differ from ERC20-compatible transfer already

Hey @Dexaran or anyone,

Is there a more detailed description on how to use your new functions? I am new to ethereum and solidity but I have a good programming background. I know that we need to use web3.js to interact with contracts, consequently I don't understand what bytes are and why we are passing them to the transfer function.

I saw one video that says that bytes represent a function signature, but how do we use it and where are we suppose to get it? (from front-end?)

I also dont understand what are we supposed to do in tokenReceived function. I just understand for now that if other contracts don't implement this method, the whole transaction fails and all state changes are reverted and gas is returned.

Thanks!

@MicahZoltu (pinging because I'm not sure there's any person with admin in this issue). Can we consider this superseded by https://eips.ethereum.org/EIPS/eip-4524?

@Pandapip1 How is it possible to figure out which EIPs are actually in widespread use? I'm trying to figure out which token standards need to be supported for maximum flexibility -- ERC-20 (obviously), ERC-223, ERC-777, EIP-2612 / Dai permits; ERC-667; EIP-1363; EIP-4524; etc. (what else did I miss?)...

I guess most relevant to this issue, is ERC-223 even in use out there?

I am going to close this as GitHub is no longer the proper place to discuss ideas for EIPs (it used to be). If the author of this wants to pursue this further, they can either create a thread on Ethereum Magicians to continue discussion, or they can create a draft EIP and start working through the EIP process as described in EIP-1.

@Dexaran

@lukehutch The EIP process is just for defining standards. Adoption is out of scope of this process, and currently there isn't any tooling I know about for determining adoption (nothing like caniuse.com for browsers).

@Dexaran there is an error in this draft... you state the prototype of symbol() as function symbol() constant returns (bytes32 _symbol), but in your reference implementation, the return type is (string memory) rather than bytes32.

Deleted a spam comment.

This EIP is still in draft.
How do we know if we should follow this standard or not?
If not then what are the reasons or security issues?
It's really difficult to read every comment and understand what everyone is stating

How do we know if we should follow this standard or not?

Draft EIPs should never be used in production. ERC-223 should not be used at all until it is moved to review. (For future readers, check the status of the EIP here: https://eips.ethereum.org/EIPS/eip-223)

I am locking this thread, as ERC-223 has its own discussion link now: https://ethereum-magicians.org/t/erc-223-token-standard/12894