Intro
This article is intended to explain the details of LEO token implementation from a technical and security point of view, the safety of using this token, as well as answer frequent questions related to this smart-contract and smart-contracts in general.
A couple of words about me
I am Dexaran, a pseudonymous crypto decentralist and developer. My main speciality is information security. I am the founder of Ethereum Commonwealth, the co-founder of Callisto Network and the creator of ERC223 token standard.
I was involved in the development of smart-contracts since the very start of Ethereum project. I witnessed numerous hacks of smart contracts. I was an active participant of TheDAO events and the creation of Ethereum CLassic. I conducted security audits for a variety of smart-contracts.
There are three things that I know very well: security, smart-contracts and crypto tokens.
LEO token contract audit
Callisto Network recently audited the LEO smart-contract. You can review the final report here. I can conclude that the token is secure from the technical side.
There are no bugs, errors or features in the contract that can directly cause the loss of investors’ funds.
Some may argue that the contract has an update function that can allow owners to destroy investors’ funds.
I will answer that such a function is indeed presented in the contract, but it does not pose a real threat to investors. This approach of smart-contract development eliminates several real threats instead. Further, I will explain it with more details and statistics.
Two LEO contracts (ERC20 and EOS)
The first thing that must be said is that LEO token is deployed on two chains — Ethereum (ERC20 contract) and EOS (EOS LEO contract).
EOS is a newer and improved smart-contracting system. Its approach is more advanced and it takes into account the experience of previous platforms, including Ethereum.
EOS smart-contracts are always upgradeable unlike Ethereum contracts that may be upgradeable or not. Why? — Because this is the best approach to make smart-contracts secure. The main problem of each smart-contract platform is smart-contract hacks. Writing the error-free code is impossible. The only viable way to make code safer is to make it fault-tolerant instead of trying to make it bug-free. As for LEO contracts — it would be weird to make one contract different from another by leaving one of them in the non-upgradeable state.
Token related issues
Many have heard of the ERC20 standard, but not everyone is aware of its problems. The problem here is that the ERC20 token standard is insecure by default and it may cause monetary losses for investors. I wrote several articles about these problems already.
The main problem is the lack of event handling mechanism in ERC20 standard. There are plenty of contracts that are not intended to work with ERC20 tokens in Ethereum blockchain. The contract must throw an error whenever a token contract is trying to deposit tokens in the inappropriate address. This is not implemented in ERC20 token by default and the lack of this mechanism results in millions of dollars losses already.
Just a couple of examples:
1. 23,458 BNB are stuck in BNB contract. $656,000 are lost.
2. 154,834 EOS tokens got stuck in the EOS token contract during the EOS crowdsale. $774,000 are lost.
3. 22,294 QTUM tokens got stuck in the QTUM token contract during the QTUM crowdsale. $1,204,273 are lost (according to the crowdsale price)
4. There are more tokens in the Ethereum blockchain that got trapped in inappropriate contracts.
Unlike nearly all the ERC20 tokens, LEO token is not prone to these issues. LEO contract implements special checks to prevent the most common cases of problems with “the lack of transaction handling”. However, the possibility to make LEO tokens stuck inside the other contracts remains because there is no standard for handling token transfers in Ethereum.
And here comes the opportunity to burn tokens in an arbitrary address. I’d like to cite this article blaming Bitfinex developers for implementation of these features.
We find it hard to imagine why a company would need to include provisions to forcefully delete the holdings of other wallets, if not to use it for censorship or undoing the immutability of transactions.
A company would definitely need this feature to save investors from losing millions of dollars by recovering their tokens from the “inappropriate transaction destinations” by minting new tokens and burning the stuck tokens from inappropriate transaction destinations. This is the only viable way to stay compatible with the most widely adopted ERC20 standard and resolve its critical problems.
Real threats in smart-contracts
The lack of upgradeability or owner control features is a threat in case of smart-contracts.
Let’s look at historical examples:
1. TheDAO was hacked and millions of dollars were stolen. On June 17, 2016, a hacker found a loophole in the coding that allowed him to drain funds from The DAO. However, the funds were placed into an account subject to a 28 day holding period so the hacker couldn’t complete his getaway. If the DAO contract was controlled or upgradeable, then the developers could use this time period to fix the bug. However, the lack of these functions and the assumption that the developers will be able to write the code with no bugs did not allow to solve the existing problem and led to the complete collapse of TheDAO project.
2. Parity Multisig was written by the developer of Solidity programming language, Gavin Wood. Parity Multisig was “hacked” twice (initWallet attack and library selfdestruct attack). The inability to make changes to the contract after committing some actions led to disastrous consequences for many users.
The lack of possibility to change or control the contract during its workflow is a real threat that already leads to millions of dollars losses. The theoretical possibility of upgrading the contract to make it possible to burn investors funds poses nearly no threat because there are no parties with real motivation to do so.
We audited more than 200 smart-contracts in Callisto. There were plenty of smart-contracts with owner’s control. This is a common practice of making contracts fault-tolerant. For the last 4 years, I have never heard that the contract owners deliberately manipulated their smart-contract to harm investors, while everyone heard about TheDAO and the lack of possibility to manipulate the contract to save investors in case of the real attack.
Misunderstanding the conception of smart-contracts
Although it is clear that the LEO smart contract was designed to be upgradeable, having such a centralized system certainly doesn’t adhere to the spirit of the new decentralized economy.
Blockchains were designed to resolve the issue of censorship-resistance. However, this does not fully apply to smart-contracts.
A smart-contract always poses the issue of trust: (1) you either trust that the developer of the contract made it bug-free OR (2) you trust that the developer of the contract will not manipulate it maliciously. You should keep in mind that writing bug-free code is almost impossible, so I don’t recommend trusting the first option.
Blockchain must provide a censorship-resistant ledger for contract invocation records while the contracts must resolve the issue of trust. If a company will manipulate the contract to harm an investor then this precedent will be transparently available for everyone to verify or prove.
While it may seem against the decentralization principles, I would say that this is the only secure option of using smart-contracts.
Conclusion
I would call LEO token one of the most secure smart-contracts in the whole Ethereum ecosystem. It is one of the few ERC20 tokens that is not prone to the common critical problems of the ERC20 standard.
The smart-contract can guarantee that investors will not suffer one of the actually-known threats that harmed multiple other token holders. The contract utilizes common modern practices of making it fault-tolerant instead of relying on archaic principles that led to millions of dollars losses.