Is a new token standard really to blame for the imBTC/Uniswap and dForce attacks?
The role of ERC-777 in teaching us new lessons.
Over the course of just one weekend, millions were stolen from smart contract accounts. The imBTC Uniswap pool was hacked and drained of 300K worth of tokens. This was shortly followed by a similar attack against dForce, though most of the stolen crypto has already been returned. Both attacks leveraged the reentrancy attack vector.
Some have claimed that certain functions of the ERC-777 token standard are the cause of these attacks. However, reentrancy attacks are a well-known vulnerability, made most famous during The DAO hack of 2016, and in fact has nothing to do with the ERC-777 token standard itself.
As this young industry develops, it’s important that we recognise the strengths and weaknesses of our protocols, encourage open collaboration and debate, and work together to improve our industry standards.
Blaming a token standard for an attack is unconstructive and feeds misinformation, and potentially puts at risk new, safer standards designed to solve the well-known problems of old ones. We can instead analyse and contribute to this evolving narrative thoughtfully. From this place of understanding is where we improve.
What is ERC-777?
Ethereum tokens are digital assets which run on its blockchain. They play a distinct and important role in the ecosystem. Each token is represented by its smart contract, which other DApps and users interact with.
As such, token standards have been introduced to simplify the interaction between the ecosystem’s many DApps and tokens. This is to foster composability. The ERC-20 standard was initially developed in 2015 as “a standard interface for tokens”. Here is a guide on how the ERC20 standard works.
Over time, Ethereum tokens have started becoming more relevant and more broadly applied within the ecosystem. With an increasing number of use cases and applications for tokens, the basic ERC-20 standard has started to reveal some limitations as more complex smart contracts make greater demands of it. In fact, the standard was originally designed to handle basic functionalities, making it unfit for a variety of use-cases.
While most tokens today follow the ERC-20 standard, a variety have added custom functionalities which better serve their needs. As a consequence, non-standard features (known as “extensions”) have been added to each token. The ERC-20 standard, for example, cannot support functions such as minting and burning, but instead must be added as an extension. In some cases different extensions have been made to address overlapping needs. This fragmentation of the ERC-20 standard makes its integration with DApps, and overall composability, unnecessarily complicated. To address this fragmentation, the community tried to agree on a new standard.
This new ERC-777 token standard was introduced last year — the result of ongoing and open discussions that lasted two years. A much more powerful standard, it “tries to improve upon the widely used ERC20 token standard” as a full and formalised extension of it. It introduces and “defines advanced features to interact with tokens”, giving token holders more control over their tokens. All ERC-777 tokens are backwards compatible with the ERC-20 standard, meaning if a DApp or wallet supports the ERC-777 standard, then it can also support ERC-20.
The ERC-20 is a simple token format. Many projects and teams have taken advantage of this simplicity and built new DApps with relative ease, growing the ecosystem and inviting innovation. However, its limitations have also presented ongoing UX challenges.
There are two main issues inherent in the ERC-20 standard which the ERC-777 standard aims to resolve:
1.ERC-20 only responds to Ether (ETH) transactions, but not to other tokens directly. This requires a two-step process to approve and then transfer tokens. This drawback has led to a number of UX problems, the most obvious being the need for 2 separate transactions just to process a single request. ERC-777 smart contracts can execute functions when receiving just tokens, removing the need for ETH to be required, streamlining the process.
2. Millions of dollars worth of tokens have been lost due to “user error”. Users often send their tokens to the smart contract, rather than the destination blockchain address. ERC-20 contracts cannot detect this error, as a standard behaviour for the `transfer` function has not been defined in the case of handling such errors. This feature of ERC20 token standard design “is a Software Bug and it can be classified as Software Vulnerability.” Comparatively, an ERC-777 smart contract is able to detect such errors and reject mistaken token transfers.
Incompatibility of the ERC-777 standard with some protocols
Particular functions of the ERC-777 standard are unique features. These functions enable interoperability among protocols, which is vital for the Ethereum ecosystem to scale.
However, because the ERC-777 token standard was only just introduced last year, these features can also result in incompatibilities with certain protocols, especially for some previously-deployed smart contracts.
Given the fast pace of Ethereum’s development, and the increasing complexity of smart contracts emerging in the decentralized finance space, it’s unsurprising that there are incompatibilities. Yet it’s important for protocols to address these as soon as possible, as they may be open to attack vectors. The same can be said for all incompatibilities, not just in the case of the ERC-777 standard.
As the adoption of this new standard grows, projects must add support for ERC-777 tokens, or otherwise implement necessary security measures, if they are to protect themselves against such attacks. Unfortunately, various projects have done neither of the above. In some cases, such as with Uniswap V.1, the issue had been made public by the team, who discouraged users from adding their ERC-777 tokens to their liquidity pools.
It also seems that it has been wrongly assumed that token transfers are considered “reentrancy safe”. Note that this assumption is never made for any other smart contract type, yet some protocols have erroneously decided to assume token transfers (and not just ETH transfers) as safer than normal. Unfortunately, this included the reentrancy attacks exploits carried out over the weekend.
An exploit via reentrancy attack happens when the functions in smart contracts which interact with each other (allow contracts to “speak” to each other and interoprate) are exploited. For example, when a user wants to swap their tokens, there can be three smart contracts involved; smart contract A (a dApp or protocol such as Uniswap) interacts with smart contract B (a token’s smart contract, such as imBTC, or another dApp or protocol), which then interacts with smart contract C (a smart contract of any kind, which can be created by an attacker with the sole purpose of stealing funds).
If smart contract C is in the control of the attacker, it can send a request for tokens but falsify the confirmation of funds received. The request to send tokens to smart contracts C is still executed, but the attacker can continue pretending that the tokens were never received. As it’s an automated process, there’s no way to interfere (unless you know that the attack is happening and can then stop the contract).
Lessons learned
This attack vector has long been exposed. As a key feature of Ethereum’s interoperability, it can be exploited in a variety of ways. Token smart contracts can also be leveraged as a tool to perform a reentrancy attack. This is what happened during the weekend’s imToken/Uniswap and dForce attacks.
It’s important to note that these attacks do not mark the end of DeFi, or even call into question the safety of the ERC-777 token standard. The number of ERC-777 tokens is steadily increasing. Teams such as Augur are deciding to upgrade their ERC-20 tokens into a ERC-777 format. As the industry also grows, it’s important that we all understand the risks of dealing with such innovative technologies and how we can minimize those risks.
The beauty of such errors is that they are errors of code, and not the same in-built, systemic flaws which are rife among the traditional finance industry — corruption, over-regulation and exclusion. Through DeFi, we have shifted trust from people to code. So while there will always be those looking to exploit that code, at least the code itself does not intend to exploit people. The same cannot be said for our economic systems today.
As an industry, we should continuously improve upon our standards, making each new iteration stronger and more secure. For now, ERC-777 offers a range of advantages that bring value to token holders and DApps. We should work towards continuous revision of this and all future standards, raising the bar higher. This is what will set DeFi apart.
🦜 Interested in pTokens? Explore the technical deep dive into our infrastructure, or check out the summary on our website.
💬 Connect with us on Twitter and join the conversation in our pNetwork Telegram and Discord.
🔗 For any blockchain project looking to integrate pTokens into their infrastructure, we have also built a pTokens JS library.
