Difference between ERC20 and ERC223?

What are ERC tokens then?

The Ethereum ecosystem is decentralized, but it still needs someone to set the rules, make decisions about upgrades, and set the standards that define what can be done on the blockchain. To achieve this, decentralized finance (Defi) development services company users themselves must create Ethereum Improvement Proposals (EIPs), discuss the details, and vote to reject or initiate their implementation. Now, there are several types of EIPs for different categories of improvements and additions.

One of these types was defined by the core developers of Ethereum to propose, discuss and implement different technical standards for the creation of tokens, smart contracts, applications, wallet formats, etc. on Ethereum.

This subcategory of EIP was named Ethereum Request for Comments, or ERC. Until now, there has been a lot of Ethereum Request for Comments to establish standards for the tokens that can be created on Ethereum. Therefore, all the tokens that are created in Ethereum must follow the standards established by these ERCs. Hence they are called ERC tokens.

Today, there are three ERC standards that are the most widely used on Ethereum: ERC20, ERC721, and ERC1155. In case you are wondering, the numbers after ERC are simply the serial numbers of the “Request for comments” that proposed those standards.

What are the standard features of ERC 20?

The ERC 20 standard recommends the accompanying capabilities while fostering an Ethereum token:

• Get the total supply of tokens: You must use the “total supply function”.
• Retrieve token balance from another owner’s accounts.
• Send tokens to another owner account: You must use the “transfer” function. These accounts are EOA accounts.
• Send tokens from one token address to another. Token addresses are contract addresses and you must use the “transfer From” function.
• Permit one more record to pull out assets from your record, inside a predetermined breaking point over and over.
• You must use the “approve” function for this.
• Spenders can return unused tokens to owners, using the “allocation” feature.

An ERC 20 bug that burns tokens

While very well documented and generally implemented, the ERC 20 standard has a bug, Metaverse and this has already burned millions of US dollars worth of tokens. The “move” capability just permits you to send tokens to another proprietor, for example EOA account.

If you have any desire to send assets to a shrewd agreement account, for example, i.e. the other form of Ethereum accounts, you need to use the “approve” and “transfer from” combination. If you send tokens to a smart contract using the “transfer” feature, you will see a successful transaction, Defi development but the contract will never receive the tokens. This burns those tokens forever and you can’t get them back. Several users have used the wrong function to send tokens to smart contracts and have lost their tokens forever! The Ethereum Establishment is familiar with the bug, however keeps on advancing the ERC 20 norm. I don’t have a clue about their explanations behind doing as such. They are probably not appreciating the importance of the problem, or there is a resistance to change.

The ERC223 Token Standard: A Proposed Resolution for the ERC 20 Bug

An Ethereum developer who goes by the Reddit username “Dexaran” proposed EIP 223 with a fix to this ERC 20 bug. Before comparing ERC 20 vs ERC 223 vs ERC 777, I will first explain his proposal. The ERC223 token standard is still a draft and has yet to be implemented by the Ethereum community. Proposes the following solution:

• Consider a transaction on the Ethereum blockchain as an event and use the concept of “event handling”.
• If users use the “transfer” function to send tokens to a smart contract, it will throw an error and subsequently cancel the transaction.
• The user pays the Ethereum “gas price”, but does not lose any tokens.
• This proposal adds an additional parameter to the “transfer” function, to check if the receiving address is a contract account.
• If you find that the recipient address is a contract account and not an EOA account, then it assumes that the contract has implemented a “Fallback token”.
• A “token Fallback” function allows the token to be retrieved, so the transaction does not burn any tokens.

Although the ERC223 solves the ERC 20 error to a great extent, there is a weakness in this proposal. If the recipient’s smart contract does not have a “token Fallback” function, then the “Fallback” function will be executed, resulting in the loss of tokens.

0