The Ethereum blockchain, as we know is among the most flexible and programmable ones. It was the first to implement Smart-Contracts and consequently the various tokens.
In this article I have already explained the difference between the various tokens (Utility, Security and NTF); in the following article, however, I will address some difficulties that can be found with the standard Utility Token protocol.
The protocol in question is the ERC-20.
A step back to the birth of a token and its associated protocol.
Let's take a look at the blockchain, precisely Ethereum, for the creation of a token, developers present to the community "Ethereum improvement proposals" called EIPs.
In these proposals, they explain the token, its protocol and the community starts using it.
As beta testers.
From this use, comments, suggestions and all those "objections" are drawn up to improve the smart-contract that manages everything.
Once the community has accepted the EIP, it becomes a standard and is called "Request for Comments Ethereum".
This happened for the progenitor of the Utility Token the ERC-20.
Virtually all ICOs from the advent of Ethereum until today have been based on this protocol.
The exact same protocol, created, however, on the BINANCE blockchain, the Binance Smart Blockchain, is called BEP-20.
This protocol has functions well defined by its own smart-contract and they are:
- Total Supply of tokens (Total Supply);
- Token balance retrieval from another account;
- Sending tokens to another account owner. These are EOA accounts, and you use the transfer feature;
- Sending tokens from one address to another. The token addresses, are clearly smart-contract addresses: for this you will use the "TransferForm" function
- Consent to another account to repeatedly withdraw funds (tokens) up to a specified limit. For this you will use the "Approve" function;
- Through the identity function, you can return unused tokens to their owners.
These are the main functions that govern the management of ERC-20 tokens, in this, however, the community did not notice a bug.
Because of this bug, several million of dollars have been lost forever in the chain of the blocks.
Let's look at it together.
As we have seen just above, we have two transfer possibilities: those between accounts and those between addresses.
If you send tokens from addresses to accounts or vice versa, the operation seems to be validated but the tokens will never be credited.
This makes them completely unrecoverable!
The ERC-223 Token
To solve this bug, the code written by a Reddit user: "Dexaran" comes to help.
Dexaran's solution consists of a simple check of addresses and accounts.
In case there are any discrepancies, the gas fees will still be paid, but the tokens will not be lost.
They will be returned to the sender via a "tokenFallBack" function.
This function is considered as default in the Samart-contract, but if it was not provided, the function will be "FallBack" and the tokens will be lost forever.
Let's say that even this solution would have a bug in it, and it consists in assuming for sure that the smart-contract has the TokenFallBack function inside.
The ERC-777 proposal
A recent proposal to improve ERC-223 is the ERC-777 protocol.
In this protocol the commands that would compromise tokens would be changed.
- Instead of "Transfer" the construct "Send" would be used.
- Instead of "Approve" the "AuthoriseOperator" command would be used.
- Instead of "TokenFallBack" the "TokensReceived" construct would be used.
Unfortunately, the developers are not yet able to know what are the functions implemented in the various smart-contracts and, for this reason, a token with ERC-820 protocol, has implemented a central register of smart-contracts on the network and the functions present.
So by launching a query to this smart-contract one can get to know the functions present in that smart contract.
With this possibility the burn of the tokens we can consider it averted, but....
As usual there is always a BUT in things that offers more challenges to programmers:
- The "AuthoriseOperator" function was suspended at the time because it commits a lot of gas to be performed and would put a strain on the network;
- A centralized registry of all functions in smart-contracts could contain bugs (as well as be hacked).
Conclusions
From what we've seen, the developer community isn't sitting idly by watching what's going on - after all, that's a lot of money being thrown around without being able to be recovered.
This factor is giving everyone an incentive to take some responsibility, so despite the risks that ERC-777 brings with it, you should use it.
What do you think?
