Integrate ZRC-223 standard for ZRC20

[Dexaran]

ERC-20 standard security flaw caused millions of dollars losses

ERC-20 token standard has a major security flaw that I disclosed to Ethereum Foundation in 2017 but they ignored it.

ERC-20 does not implement "transaction handling" for transfer function and it makes it impossible to handle erroneous transfers OR deposit tokens to contracts using the transfer function i.e. if a user sends Ether, an ERC-721 NFT token, or an ERC-223 token to a contract that does not explicitly declare that it is supposed to receive them, then the tokens or Ether are rejected and the transaction automatically fails. This doesn't work with ERC-20 - if a user sends ERC-20 to some random contract then the transaction will succeed and the tokens become "frozen" at the contract's address with no way to recover them. As of today, the described problem caused $90,000,000 to $200,000,000 financial damage to users of Ethereum tokens.

• Here is a disclosure of the ERC-20 flaw on EthereumMacigians
• I'm proposing to add it to EIPs as an informational disclosure
• It is being escalated to Ethereum editors for quite some time and we are developing a process to allow for security disclosures in "Final" EIPs currently.
• Here is a security statement

Why ERC-20 is designed the way it is

There was a bug in EthereumVM at the time when ERC-20 was developed. Pull transacting method was introduced to make tokens not affected by this bug. It was a quirk that addressed the earlydays bug in the VM, not a smart design.

• ERC-20 standard was proposed in 2015. At this time there was a bug in Ethereum Virtual Machine 1024 call stack depth. The approve & transferFrom method of the ERC-20 standard was introduced so that this bug does not affect tokens.

• In Tangerine Whistle hardfork the call stack depth problem was solved. This happened on block 2463000 in 2016. At this time approve+transferFrom method became irrelevant and the ERC-20 standard should have been considered deprecated.

Here is a @vbuterin 's comment regarding the situation with token standards and call stack depth problem:

approve & transferFrom are unnecessary now and they introduce security risks as well as they authorize third parties to operate with users funds. This is not as critical as the lack of error handling with transfer func however.

Source: ethereum/ethereum-org-website#10854 (comment)

ZRC20 is affected

ZRC20 implementation is prone to the same exact issue and will inevitably cause financial damage to your customers if it is not fixed:

https://github.com/zeta-chain/protocol-contracts/blob/main/contracts/zevm/ZRC20.sol#L178-L189

Alternative token standard support proposal

I've designed an alternative ERC-223 token standard to solve this exact problem of ERC-20 security bug and it was finalized in 2023.

Obviously ERC-20 will not go away overnight, but I'm building the ecosystem for ERC-223 tokens currently. I believe that in the long run the standard that does not burn users money will thrive. The main idea is to make ERC-20 and ERC-223 interoperable for now and let a dual standard ecosystem settle.

• I'm working on ERC-7417: Token Standard Converter https://eips.ethereum.org/EIPS/eip-7417. This Converter creates a ERC-223 "fork" for each ERC-20 token and allows users to wrap ERC-20 tokens as ERC-223 or unwrap back to ERC-20 if necessary.
• We've built the UI for token converter: https://dexaran.github.io/token-converter
• Here is a script that calculates ERC-20 losses live: https://dexaran.github.io/erc20-losses/
• I'm building Dex223, a ERC-20 & ERC-223 compatible exchange https://dex223.io/
• You can find a list of ERC-223 resources and a history of ERC-20 vs ERC-223 fight here: https://dexaran.github.io/erc223/

I'm ready to contribute to the development of the safer token standards. We can support Zeta testnet with our token converter. I can write example ERC-223 (or ZRC-223) contracts to demonstrate an alternative way of implementing tokens on Zeta Chain.

We can deploy Dex223 on Zeta chain.

[lumtis]

Hi @Dexaran thank you for the report.
However, the notion of "critical security flaw" seems over-exaggerated.
The link you posted mention about logical flaw.
Can you explain how you would consider ERC20 implementation as a security flaw?

[Dexaran]

Can you explain how you would consider ERC20 implementation as a security flaw?

It falls in "critical severity security vulnerability" criteria in OpenZeppelin bug bounty.

OpenZeppelin/openzeppelin-contracts#4451

[Dexaran]

Again, ERC-20 implementation violates some well-known principles of secure software development.

• Failsafe defaults. With ERC-20 defaults are not failsafe and the default behavior of the transfer function is to perform a transfer of value without checking for its correctness.
• Error handling is a must. The ERC-20 is designed in a way that does not allow for error handling. As a result, tokens are “lost” due to obviously erroneous transfers, which could be easily prevented if a proper communication model would be implemented. When you send Ether to contract the recipient is notified automatically which allows to handle errors.

https://owasp.org/www-project-developer-guide/draft/04-foundations/03-security-principles

Violating some widely adopted and well-documented principles of secure software development will result in your software not being secure (quite logical). Hence millions of dollars are lost due to the ERC-20 flaws that I described.

I'm not saying that your standard has a security vulnerability and someone will hack it. I'm saying that your token standard (as well as the base ERC-20 standard) is not secure by default and it will result in your users losing money without a hack.

[Dexaran]

You can probably apply a "bandage" to ZRC-20 by prohibiting direct transfers to smart-contract addresses via transfer function. This will require you to redefine some part of the Uniswap logic however as it does unchecked transfers via transfer func.

See contracts below

• Dexaran's saferZRC20: https://github.com/Dexaran/protocol-contracts/blob/main/contracts/zevm/ZRC20.sol#L179-L202
• Dexaran's saferZRC20-compatible Uniswap V2: https://github.com/Dexaran/protocol-contracts/blob/main/contracts/zevm/Uniswap.sol#L46-L51

(You can optimize the gas usage by issuing an unlimited approval at the moment of the pair contract creation to avoid multiple approve calls)