Hundreds of Millions of Dollars Locked at Ethereum 0x0 Address and Smart Contracts’ Addresses — How, Why and What to do?

Some numbers about locked money at the time of this article:

Tokens with a value of $164,817,747 is locked at 0x0 address.

Ether with a value of $9,587,230.24 ($1,327.04/ETH) is locked at 0x0 address.

EOS tokens with value of $1,040,773 are locked at EOS Token Smart Contract!

Enigma tokens with value of $1,255,279 are locked at ENG Smart Contract!

ZeroX tokens with value of $1,167,192 are locked at ZRX Smart Contract!

Augur (Rep) tokens with value of $63,343 are locked at REP Smart Contract!

Golem tokens with value of $317,200 are locked at GNT Smart Contract!

BAT tokens with value of $128,353 are locked at BAT Smart Contract!

Those are just some of the locked tokens. There more and more and more to count when we include other smart contracts and other addresses that people transfer to them by mistake.

Before indulging, I would like to highlight the importance of solving the issue of “Locked Money”. Actually, it challenges the question: “Is it a good idea to store and transfer digital money (Ether) and digital assets (Tokens) inside a programmable environment (Ethereum Platform)?”. And in different words: “Is Ethereum platform and its Smart Contracts, even those written by trusted parties, practically safe for all people to use to store and transfer money?”. If the answer is “No”, then people might go for anther platform that does not have this issue (EOS, for example, will have a mechanism to overcome such situations).

How can “Locked Money” happen, continuously?

Transferring to 0x0 address

You can use your wallet, or write a code in solidity or Web3, and simply transfer Ether or tokens (many tokens accept this) to 0x0 address instead of a desired address. People sometimes forget to enter the address they want to transfer money to. This is empty field for address is translated to 0 by some wallets (Parity as example).

Here is a reported case of Ethereum Tokens sent by mistake: https://www.reddit.com/r/ethereum/comments/5rd4co/ethereum_wallet_sends_to/.
Another discussion is there regarding Ether sent by mistake: https://www.reddit.com/r/ethereum/comments/3gwczr/be_careful_it_is_so_easy_to_make_a_mistake_and/
Here is someone talking about losing 1493 Ether: https://github.com/ethereum/EIPs/issues/156#issuecomment-342681308

Transferring to Smart Contract Address

Same as above, you can use your wallet, or write a code in solidity or Web3, and simply transfer Ether or Tokens to the address of a token (many tokens also accept this) instead of a desired address. A common mistake is that: none technical, or even technical people who are new to Ethereum, sometimes transfer tokens to the same address of the Smart Contract of the Token, instead of calling a method of that Smart Contract to transfer tokens to another address.

More Locked Ether and Tokens to be Counted

Additionally, any typing mistake will lead to transferring to a wrong address. Unfortunately, when allowing human mistakes to happen, they will happen for sure.

Whos mistake is this?

Validating a user-input is a very basic check that any mid-quality solution do. For example, you cannot even imagine a website the does not do a validation on the user’s email-format when filling out a form. Unfortunately, Ethereum, in addition to Bitcoin and many others, do not have an efficient mechanism to validate addresses. Additionally, lots of Tokens’ Smart Contracts do not have this basic validation! Moreover, some Ethereum wallets do not perform this user-input validation! In my opinion, we cannot blame people for doing mistakes while the code of there big brothers allow (I mean by big brothers: the Developers of Ethereum Platform, Smart Contracts and Wallets).

For that, I think it is the sole responsibility of us (the developers and business owners) to prevent and correct such harmful thing and to encourage best practices.

What to do to prevent more loses?

To prevent this problem in the near future: We should stop the bleeding edge by encouraging best practices for both Tokens’ Smart Contracts and Wallets.

Tokens Smart Contracts Best Practices

I contributed to ConsenSys repository for Smart Contract Best Practices at GitHub. And they the edits were merged, after deleting some sentences and paraphrasing some others while keeping the idea and the suggested code: https://github.com/ConsenSys/smart-contract-best-practices/pull/143

Actually, this section more for developers so I published it separately here: Ethereum Tokens Smart Contracts Best Practices — Prevent transferring to the 0x0 and the contract address

Wallets

Wallets should be designed to prevent transferring Tokens and Ether to the 0x0 address. They should also prevent transferring tokens to the same address of the Smart Contract. Wallets should not only show a warning. It should prevent this from happening in all cases by preventing the user action.

How to recover “Locked” Tokens and Ether?

Recover Locked Tokens

The process of recovering Locked Tokens depends on the Smart Contract of questionable Token. Practically speaking, the issues has to be presented to the Smart Contract owner were they have to be handled on a case-by-case basis.

As an example, if a token is a Mintable, similar in design to OpenZepplin Mintable Token, and the token is Burnable similar to OpenZepplin Burnable Token, then the tokens, transferred by mistake, could be reverted back using simple 2 basic steps.

1. The first step is calling the function mint(address _to, uint256 _amount) to mint tokens for the each lost amount to each address that did the mistake.
2. Second step is calling the function function burn(uint256 _value) to burn the tokens at 0x0 address of the Smart Contract. This step is just to keep things clean and keep the Total Supply as it was.

An example of a mintable token would be LAToken. Which is both mintable and burnable. But, it does not do simple user-input validation to prevent human mistakes.

However, if the token is not mintable in any way, then maybe the only thing that could be done is introducing a new Smart Contract code that is improved and performs user-input validation. There could be a migration of tokens balances from the old Smart Contract to the enhanced one.

Note: Even though, the migration of tokens from one Smart Contract address to another is not common, it happens with many tokens. One example is Maker DAO token. You can check the old Maker Smart Contract address here: https://etherscan.io/address/0xc66ea802717bfb9833400264dd12c2bceaa34a6d. And you can check the new Token here: https://etherscan.io/token/Maker.

A question can came: Why should the Smart Contract owner recover the locked Tokens? Actually, the responsibility, to recover from this situation, is of those how implemented and deployed a low-quality code, that does not do the very basic principles of user-input validation. Additionally, they are the only party who can do this.

Recover Locked Ether

For 0x0 address

I think that Locked Ether could be reverted to their original owners’ addresses, with the next fork, along with the other helpful planed updates.

Other creative solution to present, as an example, would be a special Smart Contract that is forced to be deployed to the 0x0 address (maybe to be arranged with the next hard fork). This special Smart Contract can do two basic things.

1. It enables users to claim there locked Ether. Such that, it can contain a method to return back Ether, once it is called from the same address that transferred the Ether earlier.
2. It can contain code to prevent any future transfer to the 0x0 address.

For other addresses

I think this topic invites qualitative discussions before came up with the “best” solution. However, one of the ideas, I can think of, is that if an address does not claim an owner within 5, or even 10 years for example, then Ethereum platform should enable transferring the Ether from that address back to its original address(s).

Handle Root Cause

Checksum

The reason for the lost and locked Ether and Tokens the lack of an efficient checksum algorithm. Yes, there is an algorithm that is first proposed here https://github.com/ethereum/EIPs/issues/55#issuecomment-187159063. But when counting the hundreds of millions of USD, lost and locked in the form of Ether and Tokens, we can clearly see that the current checksum fails to prevent human mistakes.

So, I think that Ethereum should implement an efficient check-sum algorithm for addresses. Just like MasterCard and Visa Card, Ethereum can implement Luhn Algorithm (Modules 10) for Checksum! However, because an Ethereum address is part of the hash of the public key, the checksum can be simply added to the end of the address. This should be on EVM protocol level. So, whenever an address is used, the checksum should be applied first.

However, to make things even better, a simple differentiation between the address of users Wallets in contrast to Tokens Smart Contract could be used. For example, addresses of user wallets could start with 1 while tokens addresses could start with 2. Again, to be efficient, the differentiation by starting with 1 or 2, should also be at Ethereum protocol level.

Paper Wallet

Additional a valid point I think is changing the process of generating addresses. Maybe having paper wallets is not good enough. For example, having additional step to register an address as a valid owned address, using a signature form the private key owner, is a good idea.

Actually, this could be an idea for a project that uses a Smart Contract. Such that, this Smart Contract enables the owner to register his/her address and enable other Smart Contracts or Wallets to validate the address by calling a read-only (view) method inside that Smart Contract. But, I think, it would be better to be implemented as part of the Ethereum platform.

More to consider

Maybe there are more areas to enhance. Lots of discussions have to be maid to improve any system, overcome issues and hash out best practice suggestions.

So, it is a call for the geniuses developers of Ethereum to rescue the innocent people who trusted the platform but have some of their Ether or tokens lost or locked. And it is a call to prevent such thing from happening in the future. Thanks to Ethereum Foundation, not like BitCoin, Ethereum can more evolve over time and can overcome any obstacle.