The Potential Impact Of ERC-777 Tokens On DeFi Protocols
Introduction
Tokens are a fundamental part of the average user’s day-to-day experience on the blockchain — they often represent currencies that can be sent between addresses, fulfilling many basic functions such as the trading, lending, borrowing, and transfer of funds.
Tokens are distinct from chain-native currencies, such as Ether on Ethereum. They are an application-level primitive, often taking the form of a smart contract that keeps track of balances and enforces rules and authorization.
In order to ensure interoperability between tokens and applications, major standards have been developed and implemented over time by developers. Of these, ERC-20 is undoubtedly the most widely adopted. However, lesser-known extensions seeking advancement, such as ERC-677, are also available.
A core security issue introduced by certain standards is the modification of behavior in previously defined smart contract methods. Specifically, ERC-777 with its addition of transfer hooks, is one of the most problematic in this regard, and has just been in the news relating to the recent Curve Finance hack. This is the main focus of this article, which is to quantify the risk to DeFi protocols in capital terms, should they not protect against ERC-777 reentrancy.
This article was written by whitehat bobface16.
A Brief Overview Of Major Token Standards
In November 2015, approximately 4 months after Ethereum’s launch, the ERC-20 standard was published for review by Fabian Vogelsteller and Vitalik Buterin. It defines the basic token functionality and interface in terms that almost every developer and security researcher is familiar with, including methods such as transfer, transferFrom, and balanceOf.
ERC-20 has since remained the most established token type across the ecosystem, with an estimated 450,000 tokens present on Ethereum alone in February 2023, as well as more across other EVM chains.
An issue that was discovered soon after the adoption of ERC-20, is that users would accidentally send their tokens to the contract address instead of the intended recipient, causing their transferred balance to become permanently locked. In the worst cases, affected users lost millions of dollars in assets. ERC-223 was subsequently presented to avoid these kinds of losses. The proposal modifies the transferring process so that when the recipient is a smart contract, the logic first ensures that it is expecting to receive tokens by calling a so-called hook on the recipient. In the case of ERC-223 this hook is named tokenReceived, and if it is not present on the recipient contract or if it fails, the transfer is aborted, thus protecting against these kinds of mistakes.
Another peculiarity of ERC-20 is that a smart contract’s code on the receiving side of a transfer does not get executed, as would be the case with native Ether transfers. For a smart contract to be able to tell where it received funds from, this has led to the poor UX of a two-step process involving approve followed by transferFrom. ERC-677 aimed to resolve this issue by adding the transferAndCall method, allowing the sender to optionally invoke the receiving contract after the transfer is complete. A popular example implementing this standard is the Chainlink (LINK) token.
Apart from the above and ERC-777, there are further token standards with transfer hooks, such as ERC-721 (NFTs). However, they modify the base interface which makes them incompatible with ERC-20 and are therefore not relevant for this analysis.
ERC-777: A New Way To Interact With a Token Contract
Finally, this brings us to this article’s focus: the ERC-777 token standard. It was first published in November 2017, with the intention of advancing the features and functionality offered by existing token contracts. It lists seven key improvements, including the introduction of approved operators that can transfer tokens on behalf of users, and registration with the ERC-1820 registry.
Security Implications
From a security perspective, the most important addition are the optional pre-transfer hooks. They differ from the previously described hooks by executing a non-read-only call (tokensToSend) to the sender of the transfer, given the sender has registered with the ERC-1820 registry beforehand. This hook hands control flow over to the sender, which can lead to the exploitation of reentrancy vulnerabilities. Consider the following simplified contract, that allows users to deposit and withdraw tokens:
Here, ERC-777 tokens deposited legitimately can be drained from the contract by an attacker by reentering the deposit function:
1. Call deposit with 0 amount (or 1 wei if the token does not support 0-value transfers) via an attack contract.
2. The Vault caches its balance and calls transferFrom.
3. The ERC-777 token contract invokes the tokensToSend hook on the attacker contract.
4. The attacker contract gains control flow and again calls deposit with 0 amount.
5. Repeat the above a couple of times.
6. After some repetitions, call deposit with a larger amount, for example 100 tokens, and stop reentering from there on.
7. The previous calls to deposit will now continue after the transferFrom line one after the other, all of which calculate received as 100 tokens, thus amplifying the attacker’s deposit by the number of reentrances.
8. Call withdraw to drain the funds.
The above issue affects protocols that intend to work with any token, such as a DEX or token bridge, yet do not consider the implications of ERC-777 tokens, and therefore do not properly protect against reentrancy.
Past Security Incidences
The simplified scenario presented with the Vault contract has led to serious hacks in the past. Most notably, Uniswap V1 did not protect against reentrancy, which caused ~$300k to be stolen from the imBTC pool. Cream Finance also suffered a similar exploit, leading to the loss of ~$18.8M, as did LendfMe, which was exploited for ~$25M. While examples in the wild may not be numerous, the damage for each individual exploit alone is substantial, showing that ERC-777 vulnerabilities present a considerable, tangible threat to crypto.
The Market Capitalization Of ERC-777 Tokens
Despite this, projects have treated such reports with a general lack of interest in the past. The common perception among them seems to be that the ERC-777 standard is old and deprecated, with no real adoption or usage in the market. In other words, that it’s not a problem worth fixing. However, the question remains: how much capital is actually tied up in this issue?
Luckily, answering this is not difficult, as the standard itself requires tokens using it to register with the aforementioned ERC-1820 registry. The registry emits an event for each call to its setInterfaceImplementer method, from which we can extract the ERC-777 tokens by checking the interfaceHash field for the hash of “ERC777Token” as per the standard. At the time of writing, this yields a count of 615 tokens.
To calculate the total circulating market capitalization of these tokens, we can utilize the CoinMarketCap API to report token pricing and circulating supply. At the time of writing, the combined market capitalization is approximately $459,605,720. Not negligible at all. Some of the largest tokens include:
- Lukso (LYXe): $138,998,727 @ 0xA8b919680258d369114910511cc87595aec0be6D
- Skale (SKL): $120,559,020 @ 0x00c83aeCC790e8a4453e5dD3B0B4b3680501a7A7
- Verasity (VRA): $44,429,110 @ 0xF411903cbC70a74d22900a5DE66A2dda66507255
- Dawn Protocol (DAWN): $42,155,332 @ 0x580c8520dEDA0a441522AEAe0f9F7A5f29629aFa
Additionally, this number represents only an estimate on the lower end, since certain implementations do not register with the ERC-1820 registry, and are thus not detected by this method. An example of this is the AMP token (0xfF20817765cB7f73d4bde2e66e067E58D11095C2), which registers under a different interfaceHash.
It currently has a circulating supply market capitalization of $130,530,352.
Summary
While ERC-777 has not found adoption near to the degree of the ERC-20 or ERC-721 standards, they still represent the equivalent of over half a billion US dollars in funds at risk. Any project that is built on the premise of allowing interaction with an ERC-20 based token type, which includes most decentralized exchanges, token bridges, or permissionless lending platforms, should be aware of the seriousness of this risk, and take steps to protect their users against the reentrancy issues posed by tokens using this standard.
