(For reference during this section, the standard can be found at the following link: https://github.com/ethereum/EIPs/issues/223)

This standard was created as a response to a potential issue with the original ERC-20 standard; namely, if a user calls transfer() with a contract account as the to address, then those tokens are lost forever. There is no way that the contract, who owns the receiving address, can itself ever call transfer(), thus rendering the tokens stuck.

ERC-223, which, at the time of writing, is still in an open draft and not finalized, attempts to remedy the problem of stuck tokens by only allowing transfers to accounts owned by contracts if those contracts have a way of handling the tokens transferred to their ownership.

The standard defines a new interface for the transfer() function, and states that any contract expecting to receive tokens must implement a tokenFallback() function, which is called as part of the transfer. If the function isn't defined, tokens cannot be transferred to the contract's ownership, making it impossible to accidentally send tokens to addresses owned by contracts if those contracts are not expecting them.

The general flow is presented in the following diagram:

Note that the transfer now only requires a single call to be initiated by Bob, as opposed to the two calls – approve() and transferFrom() – for the equivalent ERC-20 flow. This means both gas costs and blockchain state costs are reduced.

Two other important token standards, which we won't discuss in detail, but which could both be considered successors to ERC-20 and ERC-223, are ERC-677 and ERC-777.

ERC-677 was designed to make the functionalities provided by ERC-223 backward-compatible with ERC-20, while ERC-777 is particularly complex, and uses a registry contract defined in a further new standard, ERC-820, to allow any address to register which type of interface it implements. The registry then allows an ERC-777 contract to check the implementation of the to address as part of any transfer.