blocks|key|1282871|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<p>We need to bring the attention of the community. For this, I created a <a href="https://medium.com/@maltabba/hundreds-of-millions-of-dollars-locked-at-ethereum-0x0-address-and-smart-contracts-addresses-how-4144dbe3458a" rel="nofollow noreferrer">post on Medium</a> discussing the issue. I put it here also to be able to make helpful discussions regarding. Thanks for all your contribution.</p>

<hr>

<h1><strong>How this happen?!</strong></h1>

<p><strong>Transferring to 0x0 address</strong></p>

<p>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)!</p>

<p><strong>Transferring to Smart Contract Address</strong></p>

<p>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.</p>

<p><strong>More Locked Ether and Tokens to be Counted</strong></p>

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

<p><strong>Whom mistake is this?</strong></p>

<p>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.</p>

<p>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.</p>

<h1><strong>What to do to prevent more loses?</strong></h1>

<p>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.</p>

<h2>Tokens Smart Contracts Best Practices</h2>

<blockquote>
  <p>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:
  <a href="https://github.com/Muhammad-Altabba/smart-contract-best-practices/blob/master/docs/tokens.md" rel="nofollow noreferrer">https://github.com/Muhammad-Altabba/smart-contract-best-practices/blob/master/docs/tokens.md</a></p>
</blockquote>

<p><strong>Preventing transfer to the 0x0 address!</strong>
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: <a href="https://etherscan.io/address/0x0000000000000000000000000000000000000000" rel="nofollow noreferrer">https://etherscan.io/address/0x0000000000000000000000000000000000000000</a>. 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.</p>

<h2>Preventing transfer to the contract address!</h2>

<p>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.</p>

<h2>Sample Code</h2>

<p>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: <a href="https://etherscan.io/address/0xdd974d5c2e2928dea5f71b9825b8b646686bd200#code" rel="nofollow noreferrer">https://etherscan.io/address/0xdd974d5c2e2928dea5f71b9825b8b646686bd200#code</a> It is implemented using a modifier validating that the “to” address is not 0x0:</p>

<pre><code>modifier validDestination( address to ) {
    require(to != address(0x0));
    require(to != address(this) );
    _;
}
</code></pre>

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

<pre><code>function transfer(address _to, uint _value)
    [other modifiers]
    validDestination(_to)
    returns (bool) {
    (... your logic ...)
}
function transferFrom(address _from, address _to, uint _value)
    [other modifiers]
    validDestination(_to)
    returns (bool) {
    (... your logic ...)
}
</code></pre>

<p>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:</p>

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

<p>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: <a href="https://etherscan.io/address/0xe50365f5d679cb98a1dd62d6f6e58e59321bcddf#code" rel="nofollow noreferrer">https://etherscan.io/address/0xe50365f5d679cb98a1dd62d6f6e58e59321bcddf#code</a></p>

<h2>Wallets</h2>

<p>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!</p>

<h1>What to do to recover already locked tokens and ether?</h1>

<h2>Recover Locked Tokens</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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: <a href="https://etherscan.io/address/0xc66ea802717bfb9833400264dd12c2bceaa34a6d" rel="nofollow noreferrer">https://etherscan.io/address/0xc66ea802717bfb9833400264dd12c2bceaa34a6d</a>. And you can check the new token here: <a href="https://etherscan.io/token/Maker" rel="nofollow noreferrer">https://etherscan.io/token/Maker</a>.</p>

<p>A question can came: <strong>why should the smart contract owner recover the locked tokens?</strong> 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.</p>

<h2>Recover Locked Ether</h2>

<p><strong>For 0x0 address</strong></p>

<p>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.</p>

<p>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.</p>

<p><strong>For other addresses</strong></p>

<p>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).</p>

<h1>Handle Root Cause</h1>

<h2>Checksum</h2>

<p>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 <a href="https://github.com/ethereum/EIPs/issues/55#issuecomment-187159063" rel="nofollow noreferrer">https://github.com/ethereum/EIPs/issues/55#issuecomment-187159063</a>. 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.</p>

<p>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.</p>

<p>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.</p>

<h2>Paper Wallet</h2>

<p>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.</p>

<p>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.</p>

<h2>More to consider</h2>

<p>Maybe there are more areas to enhance. Lots of discussions have to be maid to improve any system and overcome issues.</p>

<blockquote>
  <p>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.</p>
</blockquote>


<p>Some numbers about locked money and they are still increasing:</p>

<ul>
<li><p>Tokens with a value of $164,817,747 is locked at 0x0 address.</p></li>
<li><p>Ether with a value of $9,587,230.24 ($1,327.04/ETH) is locked at 0x0
address.</p></li>
<li><p>EOS tokens with value of $1,040,773 are locked at EOS Token Smart
Contract!</p></li>
<li><p>Enigma tokens with value of $1,255,279 are locked at ENG Smart
Contract!</p></li>
<li><p>ZeroX tokens with value of $1,167,192 are locked at ZRX Smart
Contract!</p></li>
<li><p>Augur (Rep) tokens with value of $63,343 are locked at REP Smart
Contract!</p></li>
<li><p>Golem tokens with value of $317,200 are locked at GNT Smart Contract!</p></li>
<li><p>BAT tokens with value of $128,353 are locked at BAT Smart Contract!</p></li>
</ul>

<p>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.</p>

<p>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?”</p>

<p>So, <strong>How, Why and What to do?</strong></p>


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

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一些关于锁定货币的数字还在增加：价值为164,817,747美元的令牌被锁定在0x0地址。乙醚值为9,587,230.24美元(1,327.04美元/ETH)锁定在0x0地址。价值1,040,773美元的EOS令牌被锁定在EOS令牌智能契约中！价值1,255,279美元的神秘代币被锁定在ENG智能合同中！价值1,167,192美元的ZeroX令牌被锁定在ZRX契约！价值63,343美元的古尔( R

问数亿美元锁定在0x0地址和智能契约地址 - 的地址
EN

回答 1

Ethereum用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问数亿美元锁定在0x0地址和智能契约地址 - 的地址EN