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

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!

## 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 ) {
_;
}


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]
validDestination(_to)
returns (bool) {
}
[other modifiers]
validDestination(_to)
returns (bool) {
}


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

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

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.

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

## Checksum

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.