ERC20 Protocol Security Best Practices Guide
The ERC20 standard is one of the most widely used token standards on the blockchain. When deploying ERC20 token projects, apart from vulnerabilities in the contract code, there is also a higher risk of attacks due to the project team’s lack of understanding of token pairs or the various features involved.
These attack risks can be grouped into two categories: price manipulation and reward flaws.
- Price manipulation refers to situations where attackers can manipulate the price of a token pair to steal assets within a certain period or timeframe due to insufficient security considerations in the code or deployment.
- Reward mechanism flaws refer to situations where attackers can obtain rewards beyond the project team’s expectations due to a lack of understanding of blockchain applications or logical flaws in the implementation of the reward mechanism, enabling them to steal assets within the project.
In the following content, we will provide examples of security incidents as examples and provide relevant security best practices for ERC20 token contracts.
Price Manipulation
The attacks related to price manipulation mainly occur in the following situations:
1. Price manipulation caused by implementation differences between different token pairs of the same token.
2. Price manipulation caused by unreasonable migration mechanisms during liquidity migration.
3. Price manipulation caused by malicious control of token pair price oracles.
# Attack incidents caused by implementation differences between different token pairs of the same token
In some cases, project teams may deploy different token pairs of their project token and other tokens across various exchanges due to different requirements. However, differences in fees and other aspects between different exchanges or token pools can be exploited by attackers to manipulate prices.
## BabyDoge Attack Incident
In the BabyDoge-related token pairs, the FarmZAP contract allows for zero-fee buying and selling of BabyDoge tokens. At the same time, BabyDoge also has token pairs on PancakeSwap. When users perform transactions over a certain period of time, the deducted fees are rewarded and added to the PancakeSwap token pairs.
In this scenario, the attacker exploited the zero-fee feature of FarmZAP in the trading of BabyDoge tokens. They acquired a large amount of BabyDoge tokens by using BNB and then exchanged the acquired BabyDoge tokens for BNB through FarmZAP on PancakeSwap token pairs.
It is important to note that due to the presence of a large quantity of BabyDoge tokens in PancakeSwap, the price of BabyDoge tokens in that pair was extremely low. On the other hand, in the BabyDoge token pair, the price of BabyDoge tokens was exceptionally high due to the abundance of BNB.
Additionally, the attacker triggered the fee distribution mechanism of BabyDoge, converting more BabyDoge tokens into BNB through PancakeSwap and adding liquidity. This further decreased the price of BabyDoge in the PancakeSwap BabySwap pair.
Using the zero-fee feature of FarmZAP once again, the attacker used the obtained BNB to acquire BabyDoge tokens from PancakeSwap and then sold them in order to make a profit.
The key aspect of this [attack incident] is the amplification of the difference between BabyDoge tokens in the two token pairs through FarmZAP’s zero-fee feature and the fee distribution mechanism. This difference was exploited to steal assets from the contract.
## Security Best Practices:
In any situation, ensure consistent transaction fees (not limited to this) for the same token in different token pairs to avoid asset loss due to differences between token pairs. It is recommended to use DEXs (such as UniSwap, PancakeSwap, SushiSwap) based on the same code during the token pair creation process, as their underlying code similarity makes it easier to guarantee the consistency of token pair behavior across different DEXs.
# Attacks related to Liquidity Pool Migration
As DEXes or projects evolve, the project teams may want to create new token pools to alleviate issues such as trading fees or capital utilization among token pairs. To ensure that users’ assets are not lost and allow for convenient migration of assets or liquidity between different versions of token pairs, some exchanges allow users to migrate assets directly from the old pool without having to withdraw them first.
## Attack Incident on CellFrame
CellFrame has both old and new token pool contracts, and it supports direct migration of liquidity tokens from the old token pool to the new one. However, attackers exploited a vulnerability in the transfer logic of the liquidity migration contract.
The attacker first added liquidity to the old token pool to obtain liquidity tokens. Then, they borrowed a large amount of BNB in the old pool and replaced it with CELL tokens. During the withdrawal of liquidity from the old token pool, the severe imbalance between BNB and CELL allowed the attacker to obtain a significant amount of BNB.
Next, the attacker borrowed a large amount of CELL tokens and converted them all to BNB in the new pool. Subsequently, they transferred the liquidity tokens from the old pool to the new one. Due to the imbalance between BNB and CELL in the new pool, combined with the fact that the liquidity transfer contract calculated the liquidity transfer based on the ratio of BNB and CELL in the new pool, the difference between the two tokens as well as the presence of CELL tokens in the liquidity transfer contract led to the occurrence of the attack.
The main cause of this attack incident lies in the vulnerability in the liquidity transfer process. Although the further exploitation was facilitated by the presence of CELL tokens in the token transfer pool, the primary focus should be on the flaw in the liquidity migration process.
## Security Best Practices:
When performing liquidity migration, it is important to consider the impact of the ratio difference between the two token pairs in the old and new liquidity pools. To mitigate the security risks caused by the disparity between the old and new pools during migration, it is recommended to ensure that the token ratio difference remains within a small range during the liquidity migration process.
# Attacks Resulting from Manipulated Oracles
In some token implementations, the price of a token pair is determined by large exchanges or decentralized oracles acting as price references. Attacks can occur when these oracles are manipulated.
## SELLC Attack Event
SELLC has two liquidity pool contracts: USDT/SELLC and USDT/WBNB, as well as a miner contract. In the miner contract, the amount of SELLC tokens a user should receive is calculated based on the price in the SELLC/WBNB pool or the USDT/SELLC pool.
However, due to low liquidity in the USDT pool, an attacker took advantage of this and manipulated the price of SELLC tokens in the USDT/SELLC pool. As a result, the attacker was able to lower the price of SELLC tokens, acquire more SELLC tokens through the miner contract, and then either restore the SELLC/USDT token price or exchange SELLC tokens for WBNB in the SELLC/WBNB pool to make a profit.
The main reason for this attack (as documented in this attack event) was the low liquidity of the SELLC/USDT token pair, which was used as the price oracle in the miner contract.
## Security Best Practices:
When using other token pairs or contracts as oracles, thorough security audits must be conducted, and transparent and timely communication with users and developers is essential. Regularly assess and monitor the security of contracts and promptly address any vulnerabilities or risks. Additionally, mitigate the risk of single points of failure by diversifying across multiple token pairs or oracles.
## Read-Only Reentrancy
For vulnerability attacks caused by read-only reentrancy, you can refer to our article, which provides detailed information about related attack events and attack principles.
Flaws in Reward Mechanisms
# Failure to Consider Flash Loan Attacks in Volume-based Rewards
In some token pairs, users may be rewarded with tokens based on the volume of funds they contribute. However, the project team did not consider the characteristics of flash loan attacks or the flaws in the token reward mechanism. This can allow attackers to simulate transactions with large funds through flash loans and obtain token rewards beyond the project team’s expectations.
## SLOT Attack Event
In SLOT, users are rewarded with SLOT tokens based on the amount of flow they provide for the SLOT token, and this token pair has been added to the PancakeSwap liquidity pool.
The intention of the project team was to encourage more users to purchase SLOT tokens through this mechanism. However, due to design flaws in the reward mechanism and the failure to consider that attackers could obtain large amounts of BNB through flash loans and exchange them for SLOT, substantial rewards were given out, resulting in the theft of BNB assets from the SLOT token pool.
In this attack event, the main reason was the inadequate consideration of malicious users simulating transactions through flash loans when designing the reward mechanism for the SLOT token.
## Security Best Practices:
When designing reward mechanisms, it is crucial to consider the possibility of malicious users borrowing large amounts of assets to simulate transactions. It is recommended to set a maximum limit on the reward mechanism or implement time delays (disallowing the calculation and distribution of rewards in a single transaction) to prevent attacks caused by flash loans and similar methods.
About us
At Eocene Research, we provide the insights of intentions and security behind everything you know or don’t know of blockchain, and empower every individual and organization to answer complex questions we hadn’t even dreamed of back then.
