The WETC Double-Spend
On July 17, 2025, the WETC token project on BNB Chain suffered an exploit that drained approximately $100k USDT. This analysis examines the attack mechanics, identifies the root cause, and highlights key security lessons.
Incident Overview
Date: Jul 17, 2025
Platform: Binance Smart Chain (BSC)
Attacker Address: 0x7e7c1f0d567c0483f85e1d016718e44414cdbafe
https://bscscan.com/address/0x7e7c1f0d567c0483f85e1d016718e44414cdbafe
Vulnerable Contract:
https://bscscan.com/address/0xe7f12b72bfd6e83c237318b89512b418e7f6d7a7
Attack Transaction:
https://bscscan.com/tx/0x2b6b411adf6c452825e48b97857375ff82b9487064b2f3d5bc2ca7a5ed08d615
Attack Methodology
First, the attacker borrowed 1 million USDT from PancakeV3Pool using a flashloan. They then used 250K USDT to purchase a significant amount of WETC from the USDT/WETC pair, depleting the WETC reserves from over 10M to 2.8M.
Next, the attacker repeated the following sequence twice:
Transferred WETC to the trading pair
Used the "skim" function to redirect tokens to a specific whitelisted address in the WETC contract
Used the "sync" function to update the pair reserves to reflect the actual balance
After completing these operations, the attacker sold 3 million WETC, generating approximately 100K USDT in profit.
Technical Deep Dive: Tracing the Vulnerability
Comparing WETC token counts in the pair before and after these actions reveals a dramatic difference. Under normal circumstances, the skim function should only transfer excess tokens to the target. This discrepancy clearly indicates a vulnerability in this step.
Let's examine the transfer function of WETC that's called within the skim() function
If the from (sender) or to is a whitelisted address, the _transfer internal function will be triggered twice—once in the first if-block and again inside the transferBuy function
This sequence of actions artificially depleted the WETC balance in the trading pair beyond the intended input amount. With fewer WETC tokens in the pair, the value of each remaining token increased significantly. This price manipulation allowed the attacker to generate approximately 100K USDT in profit during the final transaction.
Root Cause Determination
The fundamental vulnerability lies in the WETC ERC20 contract's flawed transfer function implementation for whitelisted users. This flaw creates a double-spending opportunity when interacting with whitelisted addresses. The attacker exploited this vulnerability to manipulate the reserves in the WETC/USDT trading pair for profit.
Lesson learned
This incident highlights several critical security lessons for DeFi projects and users:
Keep it boring. Stick to simple transfer logic in your smart contracts; if you absolutely need to implement special features like whitelists or fee-exempt addresses, make them as straightforward as possible and subject them to rigorous testing under various scenarios. Complex transfer mechanisms often introduce unexpected vulnerabilities that attackers can exploit.
No double moves. Design your contract architecture to ensure that a single state change cannot be executed twice unintentionally. Implement a centralized approach where only one function is responsible for updating balances, and incorporate robust safeguards to prevent repeated execution of critical operations.
Test early, get a second look. Integrate comprehensive fuzzing and invariant testing into your continuous integration pipeline to automatically detect edge cases. Additionally, invest in at least one thorough external security audit from reputable firms before launching your project or implementing any significant updates. The cost of an audit is minimal compared to the potential losses from exploits.