Trader Loses $26M in ezETH Tokens: Media Blames User, Hacker Calls Out ERC-20 Flaws

My name is Dexaran. I’m a hacker, I’ve designed and executed one of the largest consensus-level attacks in the industry. In 2019 I DDOS’ed EOS network mainnet and froze it for a month by exploiting a flaw in its consensus resourcing model. EOS was ranked top7 at that time. (EOSGO report, community report) I’m a founder of one of the Ethereum Classic core development teams. (Cointelegraph’s article) I have designed the Amendment to Nakamoto consensus, a set of rules that solve 51% attacks which were the scourge of the industry for POW chains. Editor’s note: This story represents the views of the author of the story. The author is not affiliated with HackerNoon staff and wrote this story on their own. The HackerNoon editorial team has only verified the story for grammatical accuracy and does not condone/condemn any of the claims contained herein. #DYOR Accident A user lost $26,000,000 worth of ezETH tokens by sending them to a smart-contract. There are multiple articles and twitter threads claiming that this was a user mistake, for example this one by CoinTelegraph. This is incorrect. Similar user mistake would not result in a loss of Eth, NFT or ERC-223 token. Transfers to externally owned addresses and transfers to smart-contracts work differently. If the user would send tokens to a wrong address (which is not a smart-contract) or address not owned by anyone — that would be a user’s mistake. In this case however, the user deposited tokens to a smart-contract. Smart-contracts are supposed to prevent this mistakes, and they certainly can do that — for example if a user would deposit Ether (or any other native currency), NFTs (ERC-721) or ERC-223 tokens to a smart-contract which was not designed to receive them — then the tokens would not be lost. There would be a transaction error and the transfer of tokens just wouldn’t happen. Error handling is one of the most basic principles of software security. Designing software in such a way that it wouldn’t be possible to properly handle invocation errors is the same as missing onlyOwner modifier for a governance function — that would be a security problem. This is a problem of ERC-20 standard — it is designed in a way that makes error handling impossible. And this is a security problem. ERC-20 standard is insecure. In 2023, the creator of ERC-20 standard himself confirmed that this is a security issue of the standard. I have reported it in 2017 here and here. Also, I have designed the ERC-223 standard to solve this exact problem in 2017, here is the original EIP-223 thread where it’s highlighted that this standard prevents a loss of money. It’s way too easy for security companies and developers to blame users for making a mistake. However, it’s the developer’s fault that they built their applications using the insecure standard which fails to deal with users mistakes which resulted in such a disastrous damage. History I’ve highlighted that this can cause financial damage to the users while reported this to Ethereum Foundation. They did nothing. For 7 years. There were $16,000 lost because of this issue in 2017. There were $2,000,000 lost in 2018 $60,000,000 in 2023 On Nov 1, 2024 there were $90,000,000 (excluding the 25M lost in ezETH contract) Now there are $115,000,000 My team developed a script that calculates the amount of lost tokens: https://dexaran.github.io/erc20-losses In 2017 another user lost 130K. In 2020 a user lost his life savings. In 2023 a user lost $240K in one transaction. Then Poloniex hacker lost $2.5M. I’ve requested to stop promoting ERC-20 standard because of this security issue in 2017, there was no response https://github.com/ethereum/ethereum-org/issues/755. I’ve escalated this issue to EthereumCatHerders, those guys who manage EIPs in Ethereum. In 2023 they replied “we have nothing to do with security disclosures, we don’t have a process for that”. Clarification: EIPs and ERCs are proposals that anyone can submit to Ethereum. They can become standards or modifications that devs apply to how Ethereum works. They are text files in their github repo. Context: they don’t have a process to deal with security disclosures in EIPs 10 years after the launch of Ethereum project. I was proposing a method to modify how EIPs work to allow for security disclosures: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265 I proposed to add a warning on ERC-20 and document the issue in the EIPs. Here is their call, where they decided that I need to go and create another informational EIP that would disclose a vulnerability in EIP-20: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317 I did that. They rejected my disclosure EIP after that. I came up with the proposal to revive my initial idea that I described on EthereumMagicians forum that would allow security disclosures in “Security Considerations” section of EIPs in 2024 once again. Here is my discussion with EIP editors: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s As the result EIP editors told me that they are going to vote on that: https://github.com/ethcatherders/EIPIP/issues/349 My proposal was voted out. There is still no process to deal with security disclosures in EIPs. The problem of ERC-20 is not fixed. It is not even reported or documented as a problem so implementers keep reproducing it over and over again. Unfair auditors I personally reported this issue to OpenZeppelin, requesting a fix 3 times. In 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729 In 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 After they rejected the previous two, I decided to report it in a way that would demonstrate the severity of the issue, so I submitted it to their bug bounty because it fits in “critical security vulnerability” criteria according to their own rules https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022 OpenZeppelin rejected it with “public disclosure of unpatched vulnerability” (which confirms this is a security problem at least). A few days ago at Devcon7, a question was asked to that same guy from OpenZeppelin who closed an issue on their github regarding that problem: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406 6 years after it was reported and after it caused $115,000,000 loss to their users. Their response is not even true. Instead of having an open issue, they closed 3 issues that I opened and rejected any recommendations that I made. Conclusion Ethereum Foundation is censoring any attempts to highlight the problem, which caused users of the ecosystem to lose $115,000,000. The problem is not announced, disclosure is not properly handled, implementers keep reproducing it in new contracts. I think they consider that it would be too damaging for their reputation to disclose it. Auditors like OpenZeppelin are not disclosing the issue as well, probably because they have a conflict of interests as they already placed “Secure” label on hundreds of ERC-20 contracts that they audited. Devs are saying “We are just implementing the standard the way it is.” The standard is governed by EIP process, the EIP process is not built for dealing with security disclosures. EIP process must be changed. ERC-20 issue must be disclosed and properly documented. Ideally, a new standard must be implemented. Applying a set of “bandaids” on ERC-20 to mitigate the damage is better than doing nothing, but it wouldn’t solve the issue per se. Everyone saying “the problem can be solved on the wallet level” lacks security expertise. There is a principle of secure by design in software security which means that you can’t build a piece of insecure software, tell everyone how to use it so that it wouldn’t be impacting your users and pretend that it will not cause damage. Not in a financial industry. That approach might work in web design, for example, where the cost of a fault is someone not being able to load a proper font for their web page. In financial industry this results in millions of dollars being lost. It is absolutely impossible to guarantee that all wallet developers in the entire future of human civilization would always properly implement all the necessary fixes. My name is Dexaran. I’m a hacker, I’ve designed and executed one of the largest consensus-level attacks in the industry. In 2019 I DDOS’ed EOS network mainnet and froze it for a month by exploiting a flaw in its consensus resourcing model. EOS was ranked top7 at that time. (EOSGO report, community report) I’m a founder of one of the Ethereum Classic core development teams. (Cointelegraph’s article) I have designed the Amendment to Nakamoto consensus, a set of rules that solve 51% attacks which were the scourge of the industry for POW chains. My name is Dexaran. I’m a hacker, I’ve designed and executed one of the largest consensus-level attacks in the industry. In 2019 I DDOS’ed EOS network mainnet and froze it for a month by exploiting a flaw in its consensus resourcing model. EOS was ranked top7 at that time. (EOSGO report, community report) My name is Dexaran. I’m a hacker, I’ve designed and executed one of the largest consensus-level attacks in the industry . In 2019 I DDOS’ed EOS network mainnet and froze it for a month by exploiting a flaw in its consensus resourcing model. EOS was ranked top7 at that time. ( EOSGO report , community report ) My name is Dexaran. I’m a hacker, I’ve designed and executed one of the largest consensus-level attacks in the industry EOSGO report community report I’m a founder of one of the Ethereum Classic core development teams. (Cointelegraph’s article) I’m a founder of one of the Ethereum Classic core development teams . ( Cointelegraph’s article ) I’m a founder of one of the Ethereum Classic core development teams Cointelegraph’s article I have designed the Amendment to Nakamoto consensus, a set of rules that solve 51% attacks which were the scourge of the industry for POW chains. I have designed the Amendment to Nakamoto consensus , a set of rules that solve 51% attacks which were the scourge of the industry for POW chains. Amendment to Nakamoto consensus solve 51% attacks Editor’s note: This story represents the views of the author of the story. The author is not affiliated with HackerNoon staff and wrote this story on their own. The HackerNoon editorial team has only verified the story for grammatical accuracy and does not condone/condemn any of the claims contained herein. #DYOR Editor’s note: This story represents the views of the author of the story. The author is not affiliated with HackerNoon staff and wrote this story on their own. The HackerNoon editorial team has only verified the story for grammatical accuracy and does not condone/condemn any of the claims contained herein. #DYOR Accident Accident A user lost $26,000,000 worth of ezETH tokens by sending them to a smart-contract. There are multiple articles and twitter threads claiming that this was a user mistake, for example this one by CoinTelegraph . CoinTelegraph This is incorrect. Similar user mistake would not result in a loss of Eth, NFT or ERC-223 token . Transfers to externally owned addresses and transfers to smart-contracts work differently. This is incorrect. Similar user mistake would not result in a loss of Eth, NFT or ERC-223 token If the user would send tokens to a wrong address (which is not a smart-contract) or address not owned by anyone — that would be a user’s mistake. In this case however, the user deposited tokens to a smart-contract. Smart-contracts are supposed to prevent this mistakes, and they certainly can do that — for example if a user would deposit Ether (or any other native currency), NFTs (ERC-721) or ERC-223 tokens to a smart-contract which was not designed to receive them — then the tokens would not be lost. There would be a transaction error and the transfer of tokens just wouldn’t happen. ERC-223 Error handling is one of the most basic principles of software security. Designing software in such a way that it wouldn’t be possible to properly handle invocation errors is the same as missing onlyOwner modifier for a governance function — that would be a security problem. onlyOwner This is a problem of ERC-20 standard — it is designed in a way that makes error handling impossible. And this is a security problem. ERC-20 standard is insecure . In 2023, the creator of ERC-20 standard himself confirmed that this is a security issue of the standard . ERC-20 standard is insecure creator of ERC-20 standard himself confirmed that this is a security issue of the standard I have reported it in 2017 here and here . Also, I have designed the ERC-223 standard to solve this exact problem in 2017, here is the original EIP-223 thread where it’s highlighted that this standard prevents a loss of money. here here original EIP-223 It’s way too easy for security companies and developers to blame users for making a mistake. However, it’s the developer’s fault that they built their applications using the insecure standard which fails to deal with users mistakes which resulted in such a disastrous damage. It’s way too easy for security companies and developers to blame users for making a mistake. However, it’s the developer’s fault that they built their applications using the insecure standard which fails to deal with users mistakes which resulted in such a disastrous damage. History History I’ve highlighted that this can cause financial damage to the users while reported this to Ethereum Foundation. They did nothing. For 7 years. There were $16,000 lost because of this issue in 2017. There were $2,000,000 lost in 2018 $60,000,000 in 2023 On Nov 1, 2024 there were $90,000,000 (excluding the 25M lost in ezETH contract) Now there are $115,000,000 There were $16,000 lost because of this issue in 2017. There were $2,000,000 lost in 2018 $60,000,000 in 2023 On Nov 1, 2024 there were $90,000,000 (excluding the 25M lost in ezETH contract) Now there are $115,000,000 My team developed a script that calculates the amount of lost tokens: https://dexaran.github.io/erc20-losses https://dexaran.github.io/erc20-losses https://dexaran.github.io/erc20-losses In 2017 another user lost 130K. In 2020 a user lost his life savings. In 2023 a user lost $240K in one transaction. Then Poloniex hacker lost $2.5M. In 2017 another user lost 130K. In 2017 another user lost 130K. In 2020 a user lost his life savings. In 2020 a user lost his life savings. In 2023 a user lost $240K in one transaction. In 2023 a user lost $240K in one transaction. Then Poloniex hacker lost $2.5M. Then Poloniex hacker lost $2.5M. I’ve requested to stop promoting ERC-20 standard because of this security issue in 2017, there was no response https://github.com/ethereum/ethereum-org/issues/755 . https://github.com/ethereum/ethereum-org/issues/755 I’ve escalated this issue to EthereumCatHerders, those guys who manage EIPs in Ethereum. In 2023 they replied “we have nothing to do with security disclosures, we don’t have a process for that”. replied Clarification: EIPs and ERCs are proposals that anyone can submit to Ethereum. They can become standards or modifications that devs apply to how Ethereum works. They are text files in their github repo. Context: they don’t have a process to deal with security disclosures in EIPs 10 years after the launch of Ethereum project. I was proposing a method to modify how EIPs work to allow for security disclosures: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265 https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265 I proposed to add a warning on ERC-20 and document the issue in the EIPs. Here is their call, where they decided that I need to go and create another informational EIP that would disclose a vulnerability in EIP-20: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317 https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317 I did that. They rejected my disclosure EIP after that. rejected I came up with the proposal to revive my initial idea that I described on EthereumMagicians forum that would allow security disclosures in “Security Considerations” section of EIPs in 2024 once again. Here is my discussion with EIP editors: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s As the result EIP editors told me that they are going to vote on that: https://github.com/ethcatherders/EIPIP/issues/349 https://github.com/ethcatherders/EIPIP/issues/349 My proposal was voted out. There is still no process to deal with security disclosures in EIPs. The problem of ERC-20 is not fixed. It is not even reported or documented as a problem so implementers keep reproducing it over and over again. Unfair auditors Unfair auditors I personally reported this issue to OpenZeppelin, requesting a fix 3 times. In 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729 In 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 After they rejected the previous two, I decided to report it in a way that would demonstrate the severity of the issue, so I submitted it to their bug bounty because it fits in “critical security vulnerability” criteria according to their own rules https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022 In 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729 In 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729 In 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 In 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 After they rejected the previous two, I decided to report it in a way that would demonstrate the severity of the issue, so I submitted it to their bug bounty because it fits in “critical security vulnerability” criteria according to their own rules https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022 After they rejected the previous two, I decided to report it in a way that would demonstrate the severity of the issue, so I submitted it to their bug bounty because it fits in “critical security vulnerability” criteria according to their own rules https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022 OpenZeppelin rejected it with “public disclosure of unpatched vulnerability” (which confirms this is a security problem at least). A few days ago at Devcon7, a question was asked to that same guy from OpenZeppelin who closed an issue on their github regarding that problem: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406 https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406 6 years after it was reported and after it caused $115,000,000 loss to their users. Their response is not even true. Instead of having an open issue, they closed 3 issues that I opened and rejected any recommendations that I made. Conclusion Conclusion Ethereum Foundation is censoring any attempts to highlight the problem, which caused users of the ecosystem to lose $115,000,000. The problem is not announced, disclosure is not properly handled, implementers keep reproducing it in new contracts. I think they consider that it would be too damaging for their reputation to disclose it. Ethereum Foundation is censoring any attempts to highlight the problem, which caused users of the ecosystem to lose $115,000,000. The problem is not announced, disclosure is not properly handled, implementers keep reproducing it in new contracts. I think they consider that it would be too damaging for their reputation to disclose it. Ethereum Foundation is censoring any attempts to highlight the problem, which caused users of the ecosystem to lose $115,000,000. The problem is not announced, disclosure is not properly handled, implementers keep reproducing it in new contracts. I think they consider that it would be too damaging for their reputation to disclose it. Auditors like OpenZeppelin are not disclosing the issue as well, probably because they have a conflict of interests as they already placed “Secure” label on hundreds of ERC-20 contracts that they audited. Devs are saying “We are just implementing the standard the way it is.” The standard is governed by EIP process, the EIP process is not built for dealing with security disclosures. Auditors like OpenZeppelin are not disclosing the issue as well, probably because they have a conflict of interests as they already placed “Secure” label on hundreds of ERC-20 contracts that they audited. Auditors like OpenZeppelin are not disclosing the issue as well, probably because they have a conflict of interests as they already placed “Secure” label on hundreds of ERC-20 contracts that they audited. Devs are saying “We are just implementing the standard the way it is.” Devs are saying “We are just implementing the standard the way it is.” The standard is governed by EIP process, the EIP process is not built for dealing with security disclosures. The standard is governed by EIP process, the EIP process is not built for dealing with security disclosures. EIP process must be changed. ERC-20 issue must be disclosed and properly documented. Ideally, a new standard must be implemented. Applying a set of “bandaids” on ERC-20 to mitigate the damage is better than doing nothing, but it wouldn’t solve the issue per se. Everyone saying “the problem can be solved on the wallet level” lacks security expertise. There is a principle of secure by design in software security which means that you can’t build a piece of insecure software, tell everyone how to use it so that it wouldn’t be impacting your users and pretend that it will not cause damage. Not in a financial industry. That approach might work in web design, for example, where the cost of a fault is someone not being able to load a proper font for their web page. In financial industry this results in millions of dollars being lost. secure by design It is absolutely impossible to guarantee that all wallet developers in the entire future of human civilization would always properly implement all the necessary fixes.