Metropolis and ERC23. Request for explanation/suggestions.

@vbuterin @frozeman

As response to the Vitalik's speech about ERC223, I wrote this article.

EIP discussion.

You can browse original source code here or browse Aragon implementation.

I want to note that I developed ERC223 to solve the following problems:

• Tokens are often lost in contracts. You can read my article about this here. At least $13000 are already lost.

• The way ERC20 tokens are deposited in a contract is too complicated for ordinary users. Users should be abstracted from the internal logic of the contract.

• Impossibility of handling incoming token-transactions is confusing for ordinary developers.

I don't consider this implementation more complex. I used a well-known event handling method in programming.

I'm aiming to create a good token standard, which will take into account the experience of the ERC20. My main goals are:

• Solve and prevent ERC20 current issues like token losses.

• Make tokens which would match Ethereum ideology of uniformity. When a user needs to transfer his funds, he must always perform the transfer function. Doesn't matter is user depositing in contract or sending to an address.

• Make tokens, which will be convenient for users and developers to interact with.

I'm ready to update the current ERC223 implementation with any suggestion that will make it more compatible with Metropolis (EIP #86).

I know there are wallet-addresses and contracts now. There would be wallet-contracts and contracts in Metropolis. The following points are not clear for me and I'm looking for explanation/suggestions:

1) Will wallet-contract contain executable code that can override default functions like fallback?

It's important to know because of default empty contracts can't receive Ether. You need to implement fallback function and make it payable to allow contract to receive transactions.

2) What will wallet-contract contain by default?

Current wallet can receive Ether or any token by default. This should be same in Metropolis.

3) How can I check whether the receiver is a wallet-contract or a contract?

Contracts are fully automated. They must always handle incoming transactions. If someone sent tokens to contract and there was no tokenFallback function in this contract transaction must fail. (Analogue of Ether transaction that is executing fallback function inside contract but no fallback function is defined in this contract)

Any wallet accepts Ether and any token. There is no need to try to execute tokenFallback when transferring to wallet-address now. I need to know if this will change in Metropolis?

Will the Metropolis wallet-contracts handle incoming transactions or receive everything as it is now?

4) Is there a way to check if the receiver contains a tokenFallback function or this function is not defined?

There are 3 possible scenarios for token transactions:

• Receiver is a contract. tokenFallback function must be executed. If there is no tokenFallback function in this contract transaction will fail.

• Receiver is a wallet-contract and tokenFallback function is not defined in this wallet-contract. Transaction must submit without a try to execute tokenFallback.

• Receiver is a wallet-contract and tokenFallback function is defined in this wallet-contract. tokenFallback function must be executed.