ERC233是一个通证标准，解决ERC20的以下问题：

1）容易被错误转账到合约地址，然后不可找回

2）无法在收到转账时进行相应处理

3）与ETH的转账逻辑不一致，即应该永远使用transfer（而非approve和transferFrom）

简单来说，ERC233代币在转账时，如果接收方是合约，则必须调用接收合约的tokenReceived函数，让合约处理接收。 function tokenReceived(address _from, uint _value, bytes calldata _data)

如果tokenReceived不存在，则交易失败。接收合约的tokenReceived函数还需要检测收到的代币是否允许接受（比如只支持WBTC）

另外，还新增了一个带有bytes参数的transfer函数，该参数会被递交到tokenReceived的_data。 function transfer(address _to, uint _value, bytes calldata _data) returns (bool)

由于接收合约必须有tokenReceived函数，否则交易就会失败，ERC233明显会造成大量兼容性问题。

ERC677在两个月后发表，为了保证兼容性，他只在ERC20的基础上增加一个transferAndCall函数。

transferAndCall和ERC233的普通transfer类似，转账后会调用接收合约的onTokenTransfer函数（类似tokenReceived） function onTokenTransfer(address from, uint256 amount, bytes data) returns (bool success)

在DEX中的应用 用户不再需要approve，可以用一次交易完成兑换。

在Web3上的应用 假设每个用户都拥有一个社交合约，可以用于接收打赏。现在用户可以限制接受的币种（并且防止收到垃圾币），在收到打赏后可以自动做出反应。

在Chainlink中的应用 Chainlink的服务需要LINK代币支付费用，使用transferAndCall进行付费和调用。例如向特定预言机发送任务请求： link.transferAndCall(_oracle, _payment, encodeRequest(_req))

局限性 一个接收合约支持多种业务类型时，由于只有transferAndCall一个入口，可能不利于代码编写。