š§Ø No private keys leaked, no phishing links clicked, and $820,000 was still drained
Around October 22, a token called NEM on BNB Chain (contract: NemTokenV2ādonāt confuse it with the established NEM/XEM) was reported to have had about $820,000 drained from its USDT/NEM pool on PancakeSwap. CertiK also flagged the attack, which involved roughly $820,000.
The problem was in the tokenās own code. According to SlowMistās analysis, someone on X laid out the general sequence:
š¹ The contract treated any operation that ātransferred tokens into the poolā as a āsell,ā then recorded an amount to be burnedābut didnāt check whether a swap had actually taken place.
š¹ The attacker transferred tokens into the pool, then used skim() to pull them straight back out, leaving the burn allowance behind.
š¹ Next, they called flushLpSellRecycle() to burn NEM that was already in the pool.
š¹ They repeated this 42 times. The poolās NEM dwindled as its price climbed, and the attacker eventually swapped their remaining NEM for USDT.
The transactions are publicly viewable on BscScan.
My take: Lots of small-cap tokens like to add bells and whistles such as āauto-burn,ā āredistribution,ā and āsell tax.ā Theyāre promoted as deflationary benefits, but every extra feature means more code that could go wrong. In this case, there was no need for a hackerāthe code drained the pool all by itself.
When you come across a new token with special mechanics, check at least three things first: Is the contract source code verified? Does it use custom transfer logic? Did the audit cover interactions with the pool?
When you buy tokens, do you check the contract, or just look at the chart and community buzz? š
#BNBChain #DeFiå®å Ø #PancakeSwap #OnChainRisk
Around October 22, a token called NEM on BNB Chain (contract: NemTokenV2ādonāt confuse it with the established NEM/XEM) was reported to have had about $820,000 drained from its USDT/NEM pool on PancakeSwap. CertiK also flagged the attack, which involved roughly $820,000.
The problem was in the tokenās own code. According to SlowMistās analysis, someone on X laid out the general sequence:
š¹ The contract treated any operation that ātransferred tokens into the poolā as a āsell,ā then recorded an amount to be burnedābut didnāt check whether a swap had actually taken place.
š¹ The attacker transferred tokens into the pool, then used skim() to pull them straight back out, leaving the burn allowance behind.
š¹ Next, they called flushLpSellRecycle() to burn NEM that was already in the pool.
š¹ They repeated this 42 times. The poolās NEM dwindled as its price climbed, and the attacker eventually swapped their remaining NEM for USDT.
The transactions are publicly viewable on BscScan.
My take: Lots of small-cap tokens like to add bells and whistles such as āauto-burn,ā āredistribution,ā and āsell tax.ā Theyāre promoted as deflationary benefits, but every extra feature means more code that could go wrong. In this case, there was no need for a hackerāthe code drained the pool all by itself.
When you come across a new token with special mechanics, check at least three things first: Is the contract source code verified? Does it use custom transfer logic? Did the audit cover interactions with the pool?
When you buy tokens, do you check the contract, or just look at the chart and community buzz? š
#BNBChain #DeFiå®å Ø #PancakeSwap #OnChainRisk