The creators of the MUST asset tokens platform described the complexities encountered in creating a basic smart contract and choosing a token standard.
Over the last thousand days on the Ethereum platform, almost one hundred thousand unique tokens appeared. The first of them experienced serious compatibility problems - each token had its own type of smart contract, and in order for it to be placed on the exchange or in a cryptocurrency wallet, one had to write an individual code.
To solve this problem, the developers have created a set of six mandatory and three recommended parameters of a smart contract for the release and exchange of tokens - the standard ERC20. This allowed unifying the software code of wallets and exchanges to work with any tokens in this standard.
The adoption of the standard can be considered a turning point in the industry - an already simple open source platform guaranteed compatibility with key financial services for any project. According to EtherScan, the number of compatible ERC20 smart contracts exceeded 93,000. Even assuming that there are only one hundred projects currently operating, we have a thousand teams of programmers and developers actively working with the Ethereum standard.
However, in fact, the standard in its current form has accumulated a lot of justified claims regarding the security of transactions and functionality, so in 2017 one by one began to appear updated protocols - 223, 677, 777, 827 and many others.
"For our purposes, the standard ERC20 is not suitable for many reasons," says MUST project's blockchain architector Kirill Varlamov. "For example, the MUST token should burn when it arrives on a payment contract within the platform, even this primitive cannot be implemented on the ERC20. To implement more complex logic, we will have to use the native mechanics of the blockchain. "
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 removing tokens - 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 user GitHub under the nickname Dexaran, who proposed the standard ERC223, discovered the frozen tokens QTUM, EOS, GNT, STORJ, TRONIX, DGD and OMG frozen in the contracts for more than three million dollars. 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 significant claim to the ERC20 standard is that the contracts in this protocol do not automatically send notification of receipt necessary to implement even the simplest autonomous logic of a reliable smart contract. "Two protocols complied with this requirement - 777th, a set of parameters that is fresh and taking into account many tasks of technological projects, and ERC223, represented by dozens of working tokens," Varlamov said.
As the developers reasonably believe, choosing a new standard, it should be borne in mind that many of them are still in the stage of active discussion. It is impossible to modify a smart contract after startup, so in the future, if the ERC standard is changed, for example, according to the requirements of exchanges to implement the listing, the token may cease to be compatible.
The study of the new protocols showed that the only common one is ERC223 - the transaction analysis on the Ethereum network, conducted by the MUST team, found 30 live projects that were active at least once for 3 days. Five of the projects implemented in the standard ERC223 were listed on major exchanges, including decentralized ones.
CEO of MUST, Anton Redko believes this factor is key when choosing a standard for tokens: "The main thing in our case is the prevalence of the contract, as MUST plans to list immediately after the token sale. If in respect of the code, you can look for compromises and be at least somewhat flexible, then in the case when this code does not support exchanges and purses, flexibility will not help. "
The assessment of risks and opportunities led the MUST team to a compromise option. "We decided not to take risks and stopped on the golden middle between novelty and liquidity. The MUST Token is implemented on the 223 protocol, which simultaneously solves both the functional tasks and does not create risks for the liquidity of our basic unit, "Kirill Varlamov emphasized.
Posted from my blog with SteemPress : https://coinatory.com/2018/06/23/ethereum-standards-how-to-find-a-compromise-between-functionality-and-liquidity/