Some numbers about locked money and they are still increasing:

  • 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.

I like to highlight the importance of solving the issue of locked money. Actually, it really changeling the question: “Is it a good idea to store and transfer digital money and digital assets inside something that is programmable?”. And in different words: “Is Ethereum platform and its Smart Contracts, even those written by trusted parties, practically safe for all people to store and transfer money?”

So, How, Why and What to do?

1 Answer 1


We need to bring the attention of the community. For this, I created a post on Medium discussing the issue. I put it here also to be able to make helpful discussions regarding. Thanks for all your contribution.

How this happen?!

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 translated to 0 address by some wallets (Parity as example)!

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 a the address of a token (many tokens also accept this!) instead of a desired address. None technical, or even technical people who are new to Ethereum, sometimes transfer tokens to the address of the smart contract 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.

Whom mistake is this?

Validating 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 email format. But Ethereum, in addition to Bitcoin and many others, still did not have an efficient mechanism to validate addresses. Additionally, lots of tokens’ smart contracts does not do this basic validation! Moreover, some Ethereum wallets does do this user-input validation! In my opinion, we cannot blame people for doing such mistakes while the code of there big brothers allow.

Personally, I cannot imagine that a system with a cap of hundreds of billions and tokens where many of them with caps of hundreds of millions could have such an issue. For that, I think it is the sole responsibility of us (the developers and business owners) to prevent and correct such harmful thing.

What to do to prevent more loses?

To prevent this problem for 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 tried to contribute to ConsenSys repository for Smart Contract Best Practices at GitHub at 5 Dec 2017. But, after more than a month and a half, my contribution still not yet accepted nor rejected. You can check my proposed recommendation to make a this as part of the standard best-practice at: https://github.com/Muhammad-Altabba/smart-contract-best-practices/blob/master/docs/tokens.md

Preventing transfer to the 0x0 address! If you allow human mistakes, it will happen. By the time of writing this document, the address 0x0000000000000000000000000000000000000000 contains tokens with a value of more than 80$ millions! And it is still increasing: https://etherscan.io/address/0x0000000000000000000000000000000000000000. You can see at 0x0 address that lots of token stuck, for example: AMIS, Arcade, LAToken and many others. Just because of the careless or ignorance of the Smart Contract! However, as you can see, there are also more than 7 thousands Ether at this 0x0 address. But, Ether could be easily resend back to its original addresses with a special or the next hard-fork. Whereas, sending the tokens back to there owners will be the responsibility of each token’s developers. And it will depends if the token is mintable or not. So preventing this from happening will cost you less headache later.

Preventing transfer to the contract address!

Another human mistake that you should prevent is the transfer to the same address of the smart contract. To see an example of how this could be harmful to innocent people you can check that lots of EOS Tokens (more than 90,000) are just stuck at the contract address. Another example is the LATToken. Tokens were just transferred to the contract address by mistake and the contract did not prevent that.

Sample Code

To see a good example of implementing both: Preventing transfer to the 0x0 address and Preventing transfer to the contract address, you can check the smart contract of KyberNetwork token: https://etherscan.io/address/0xdd974d5c2e2928dea5f71b9825b8b646686bd200#code It is implemented using a modifier validating that the “to” address is not 0x0:

modifier validDestination( address to ) {
    require(to != address(0x0));
    require(to != address(this) );

And the modifier should be applied on both “transfer” and “transferFrom” methods. The following is an example:

function transfer(address _to, uint _value)
    [other modifiers]
    returns (bool) {
    (... your logic ...)
function transferFrom(address _from, address _to, uint _value)
    [other modifiers]
    returns (bool) {
    (... your logic ...)

Another examples of tokens that prevent transferring to 0x0 address as well as the smart contract address are: Status Network Token (SNT), Cindicator (CND) and Bounty0x Token. There code is not as clean as Kyber Network Crystals. Yet it do the job. They use the following code snippet:

// Do not allow transfer to 0x0 or the token contract itself
if ((_to == 0) || (_to == address(this))) throw;

To check a bad example of an ERC 20 token that is mintable and have fair complexity, but yet did not take in consideration the above mentioned, you can see LAToken code at: https://etherscan.io/address/0xe50365f5d679cb98a1dd62d6f6e58e59321bcddf#code


Wallets should prevent transferring to 0x0 address and 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!

What to do to recover already locked tokens and ether?

Recover Locked Tokens

It depend on the smart contract of token. And has to be handled case-by-case and most likely will need to be handled by contract owner.

For example, if tokens are mitable token that is similar 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. The first step is calling function mint(address _to, uint256 _amount)’ to mint tokens for the each lost amount to each address that did the mistake. Second step is calling function burn(uint256 _value) to burn the tokens at 0x0 address or the smart contract address. The second step is just to keep things clean and keep the total supply as it was.

An example of a mintable token is LAToken. Which is both mintable and burnable. But, it does not do 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 which is improved and performs user-input validation. And there could be a migration of tokens balances from the old contract to the new enhanced one.

Note that, even though, 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, it is the responsibility of those how implemented a low-quality code, that does not do the very basic principles of user-input validation, to recover the situation. Additionally, they are the only one who can do. So, they should take their responsibility and not just try to make excuses.

Recover Locked Ether

For 0x0 address

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

Other creative solution could present also like for example a special smart contract could be forced to be deployed to 0x0 address (maybe with the next hard fork). This special smart contract can do two basic things. First, 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 early transferred the Ether. Second, this smart contract can contain code to prevent any future transfer to 0x0 address.

For other addresses

I think this will need long discussions before came up with the best solution. However, one of the ideas, I can think about, 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


The reason for the lost and locked Ether and Tokens is that there is no efficient checksum algorithm applied! 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 fail 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, has also to be at Ethereum protocol level.

Paper Wallet

Additional 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 of a project that uses a smart contract. Such that, this smart contract enables the owner to register his/here 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, this is 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 and overcome issues.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.