ERC223: how we chose the MUST token standard
The publication and audit of our first smart contract stopped before we started. Created in the logic of the most common ERC20 protocol, it should provide the project with absolute compatibility with the entire infrastructure of the token market — exchanges, including decentralized ones, and crypto-currency wallets. However, immediately after token sale, the token mechanics foresees automatic coin burning when used inside the MUST platform. As it turned out, the features of the protocol do not allow implementing such autonomous business logic on a smart contract.
The shortlist of candidates for decorating the proud name of MUST included the following standards: ERC223, ERC677, ERC777 and ERC827. Put aside dozens of pages of team discussions in messengers, disputes and arguing ad hominem, we identified several key points that determined the final choice.
The main complaint to the ERC20 protocol is that it allows for the loss of coins when transferring to a contract that does not have methods for token withdrawal — a contract that is not programmed to work with this standard will freeze the entire amount of the transfer forever. As of the end of December, the GitHub user under the nickname Dexaran, who proposed the standard ERC223, discovered the QTUM, EOS, GNT, STORJ, TRONIX, DGD and OMG tokens worth more than $3 million frozen in the contracts. However, the due diligence of developers usually reduces the likelihood of such transactions to an insignificantly small number — the amount of losses does not go to any comparison with the overall capitalization of these coins.
The second and essential point for our project is that implementation of the simplest autonomous logic of a reliable smart contract demands the transfer of the token to be followed by receipt notification from the receiving contract. This requirement was met by two protocols: ERC777, a fresh set of parameters that takes into account many tasks of technological projects, and ERC223, already represented by dozens of working tokens. The danger in the case of the new protocols is that they are still in the stage of active discussion. If we take them as a basis now, then in the future, when the standard is changed, our tokens will cease to be compatible.
Finally, the third and most important thing in our case is the popularity of the contract, as MUST plans exchange listing immediately after token sale. In respect of the code you can look for compromises and be at least somewhat flexible, but in the case when this code published is not supported by exchanges and wallets, flexibility will not help. Analyzing these protocols, we found out that the most common is ERC223 — it is used in 30 live projects, five of which were listed on major exchanges, including decentralized. The second most popular alternative ERC677 revealed only one live project, active at least once for three days.
Having assessed the risks, we decided on a compromise option. The MUST Token is implemented on the 223th protocol, which simultaneously solves both the functional tasks and does not create risks for the liquidity of our basic unit.
