Burned From the Inside: How the NEM (Newmont) Token Lost $822K on BNB Chain, and Where the Money Went

BlockintAI · 2026-10-23T14:00:00.000Z

BlockintAI research. Balances and transactions were re-checked on Thursday, October 22, 2026, at about 7:17 AM Central Time (CT), using public BNB Chain and Ethereum data and the BscScan and Etherscan records linked below. Times are CT unless marked UTC. USDT on BNB Chain is the Binance-Peg version.

Most token exploits break something the developers didn't think about. This one used a feature they built on purpose.

NEM is a small BNB Chain token whose contract calls itself "Newmont." It has a burn feature that takes NEM straight out of its own PancakeSwap pool and destroys it, so each NEM left in the pool should be worth more. On the night of Tuesday, October 20, someone found they could trigger that burn over and over without really selling anything. At 10:28 PM CT they shrank the pool's NEM to about 29 tokens, then sold into it and pulled out 821,920 USDT.

Most of the money left BNB Chain about 10 minutes later. By 10:48 PM CT it was 296 ETH on Ethereum, and it was still there when we checked on Thursday morning.

Key facts


What was hit	The PancakeSwap USDT/NEM pool 0x840e19dcca541ee0b55a3c67e900a39d523b12b8 for the NEM token, contract NemTokenV2 0x9cf0e3ad4efa7ab602d7b5a38c55795cfa777777 (name "Newmont", symbol NEM)
When	Oct 20, 2026, 10:28:50 PM CT (Oct 21, 03:28:50 UTC), one transaction in BNB Chain block 128,866,147
Loss	The pool lost a net 821,920.44 USDT, matching SlowMist's figure. CertiK, TenArmor and BlockSec Phalcon each put it at about $820K. The attacker kept 726,307.10 USDT after paying about 95,613 USDT in flash-loan and pool fees
Who	Attacker wallet 0xfd929b0f270dfea6c4827262b4e2bf6ea50fe9b6 (it sent the attack transaction) and attack contract 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2 (created by that wallet two minutes earlier), both named by SlowMist
How	NemTokenV2 treated any NEM transferred into the pool as a sale and queued part of it to be burned from the pool. The attacker repeated "transfer in, skim back out, burn" 42 times, then sold
Where it went	10:38 PM CT: bridged through Relay to the same address on Ethereum (725,384.76 USDT arrived 33 seconds later). 10:46–10:47 PM CT: swapped through CoW Protocol for 296.19 ETH
Today	The attacker address still held 296.19 ETH on Ethereum and no USDT on either chain (Oct 22, 7:17 AM CT). The NEM pool held 1,787 USDT
BlockintAI report	NEM (Newmont) token exploit: attacker wallet and attack contract

The feature that became the bug

NemTokenV2 went live on August 31, 2026, at 11:11 AM CT. One transaction deployed the contract and created its PancakeSwap pair with USDT. The total supply is fixed at 210 million NEM. The contract's verified source code on BscScan sets out the token's rules.

The rules punish selling. Every sale pays a 5% tax, and an extra "anti-dump" tax kicks in once the price has dropped more than 5% below a reference price. There is also what the code calls an "LP sell-destroy" step. After a sale, 70% of the NEM that reached the pool goes into a running total called pendingLpSellRecycle. The next time anyone calls the public function flushLpSellRecycle(), the contract burns that much NEM out of the pool's own balance, capped at 20% of the pool's NEM per call. It then calls the pool's sync() so the pool updates its books.

The burn only removes NEM. The USDT stays put, so NEM gets more expensive.

The flaw sits in how the contract decides that a sale happened. In NemTokenV2's _transfer function, any transfer whose destination is the pool is handled as a sale, and its net amount is added to the pending burn. Nothing checks that a swap followed. SlowMist's summary: the contract "credited transfers into the LP pair as sell volume without verifying swap settlement."

PancakeSwap pools have a standard function, skim(), that lets anyone collect tokens sitting in the pool above its recorded reserves. So an attacker can send NEM into the pool, which queues a burn, and then skim the same NEM straight back out. The burn stays queued, and the next flush takes it out of NEM that was already in the pool. CertiK put it this way: the pending value "created when tokens enter pool, remained after they left, allowing existing NEM reserve be burned and manipulated."

October 20: the setup

The NEM came from a second wallet. The attacker wallet got its first BNB, 0.007, at 8:00 PM CT. It came from 0x96cb6bec56e43b2f16c05e1af4776fbc7b9713b5, and that same wallet sent it most of its NEM: 767,818 NEM in 16 transfers between 8:28 and 10:27 PM CT.

That second wallet had been busy all day. Its first activity was at 9:53 AM CT, when it received 0.033 BNB through a cross-chain swap contract whose verified source code is named "RFQVaultExecutor." Two USDT deliveries through the same contract followed, 24,478 USDT at 9:55 AM and 24,139 USDT at 9:37 PM. It then added and removed liquidity in NEM's separate PancakeSwap V3 pool dozens of times. That cost it roughly 36,600 USDT net and left it with about 780,800 NEM. NemTokenV2's buy controls only watch the original V2 pool, so they didn't apply there.

None of the security firms name this wallet. The chain shows only that it funded the attacker and supplied its NEM.

Six practice runs. Between 8:32 and 10:14 PM CT, the attacker wallet deployed six contracts, sent each one NEM and a dust amount of wrapped BNB, and called them. All 13 of those calls failed. Each time, it withdrew the NEM and tried again with a new contract.

The seventh contract, 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2, was deployed at 10:26:48 PM CT. The attacker loaded it with 767,811 NEM at 10:28:30 PM. Twenty seconds later it called it.

10:28 PM: the transaction

Just before the attack, the pool held 933,469.41 USDT and 53.22 million NEM, which priced NEM at about $0.0175. Our step-by-step read of the transaction's 1,608 event logs agrees with the descriptions from SlowMist, BlockSec Phalcon and Defimon Alerts:

Borrow. The attack contract took 235,785,000 USDT in flash loans from 21 lenders and pools. Defimon lists Moolah, Venus and PancakeSwap V3 and V4 among them.
Buy almost all the NEM. It put the full $235.8 million into the pool and took out 53.0 million NEM, about 99.6% of the pool's NEM. That left 236.7 million USDT against 210,382 NEM.
Burn the rest, 42 times. It sent NEM into the pool, skimmed it back out and called the flush. The contract burned 20% of the pool's NEM each round. After 42 rounds the pool held 236.7 million USDT and 29.44 NEM. In total, 210,352 NEM went to the burn address.
Sell. It sold 75,693.74 NEM into a pool that thought it held only 29. The pool paid out 236,606,920.44 USDT.
Repay and keep the rest. The lenders got back all 235,785,000 USDT, plus 95,613.34 USDT in fees spread across 16 of them. The last transfer in the transaction sent 726,307.10 USDT to the attacker wallet.

The pool started with 933,469 USDT and ended with 111,549 USDT. That 821,920 USDT gap is the loss SlowMist reports. The $726K figure Defimon gives is what the attacker kept after fees.

One more detail from the code bears on step 2. NemTokenV2 lets the pool pay out NEM only when public buying is switched on or when the recipient is on the token's buy whitelist. Public buying was switched off when we checked on October 22; its setting at the moment of the attack can't be read from public nodes. The attack sent the 53 million NEM it bought, and the NEM it skimmed back, to 0x0003…10de, an address on that whitelist. That address received all 210 million NEM when the contract was deployed and supplied the pool's starting liquidity. It now holds about 53.6 million NEM, nearly all of it received in the attack transaction.

The pool emptied out. After the attack, the 75,000-odd NEM in the pool were valued against 111,549 USDT, so anyone still holding NEM could sell at a price that had jumped about 80-fold. Within about a quarter-hour, other sellers had taken out most of what was left. By 3:02 AM CT on October 21, the pool held under 1,800 USDT. On Thursday morning it held 1,787 USDT.

Where the money went

The attacker didn't wait. Every step below is on-chain, and the whole exit took about 22 minutes.

10:38:38 PM CT, bridge. The wallet sent all 726,307.10 USDT into Relay, a cross-chain bridge, through Relay's depository contract on BNB Chain. Relay's public request record shows it as a successful transfer to the same address on Ethereum. At 10:39:11 PM CT, Etherscan shows a "Relay: Solver" paying 725,384.76 USDT (Ethereum's native USDT) to 0xfd929b0f…fe9b6 through "Relay: Router V3."
10:40–10:41 PM CT, gas money. A second small transaction turned the wallet's 0.009 BNB into a few dollars of USDC and sent it to Ethereum, where 0.0027 ETH arrived at 10:41:23 PM.
10:45:35 PM CT, setup on Ethereum. The wallet signed an EIP-7702 authorization pointing at a smart-account contract (verified source name "EIP7702StatelessDeleGator"). In the same transaction it approved USDT for CoW Protocol and pre-signed a sell order.
10:46:11–10:47:47 PM CT, swap to ETH. Three CoW Protocol settlements (Etherscan tag "CoW Protocol: GPv2Settlement") sold 250,000, 250,000 and 225,384.76 USDT for 102.06, 102.09 and 92.04 ETH. That's 296.19 ETH in total.
10:51:23 PM CT, cleanup. The wallet signed a second authorization, this time to the zero address, which removed the smart-account code. On Ethereum it now looks like an ordinary wallet again.

The speed mattered. Tether can freeze USDT at a specific address, and both chains' versions of USDT passed through this wallet. By 10:48 PM CT none was left; it had all become ETH, which no issuer can freeze. On October 22 the wallet wasn't on Tether's blacklist, and the address wasn't on the OFAC sanctions list.

Where it stands. At 7:17 AM CT on October 22, the attacker address held 296.19 ETH on Ethereum, worth about $710,000 at Etherscan's price that morning. Nothing has gone out since the 10:51 PM cleanup, and nothing has gone to Tornado Cash or any exchange. On BNB Chain it holds 0.0004 BNB and one NEM. The token's rules make every wallet keep at least one, so a wallet can never be fully emptied of NEM.

Defimon describes the attacker as "a fresh Tornado-funded EOA." On BNB Chain, the BNB we traced came from the supplier wallet, which got its own BNB and USDT through the RFQVaultExecutor swap contract. That contract's BNB Chain records don't name the chain the money started on.

A day before anyone noticed

The attack happened on Tuesday night, Central time. The first public alert we found, from TenArmor, came at 3:45 AM CT on Thursday, October 22, about 29 hours later. SlowMist followed at 4:52 AM, CertiK at 5:09 AM, Defimon at 5:12 AM and BlockSec Phalcon at 5:59 AM. By then the money had been ETH on another chain for more than a day.

We found no statement from the NEM project on X. Since October 21, near-identical posts have urged NEM holders to "vote" for the token on CoinMarketCap. Each gives a different "Listing ID," and every link we checked leads to helpvote[.]help, not to CoinMarketCap. The same template, pointing to the same site, is being posted for dozens of other tokens, so it isn't specific to NEM, and nothing we found ties it to the attacker. MetaMask's public phishing blocklist lists helpvote[.]help.

What builders and holders can take from it

A transfer isn't a trade. A token that charges or burns on "sells" needs to confirm a sale actually happened, not just that tokens arrived at the pool. Any rule that reacts to tokens landing in a pool has to survive skim(), which lets anyone take tokens back out.
Public functions that move pool balances are attack surface. Anyone could call flushLpSellRecycle(). A function that burns from a pool and re-syncs its reserves can be used to set the price, and here the attacker could call it as often as they liked.
Watch for rehearsals. Six failed contracts and 13 failed calls in two hours, all aimed at the same token, made a visible warning before the real attack. Monitoring that flags repeated failed calls against a token or pool can buy a team time.
Holders: ignore "vote," "airdrop" and "recovery" links. Use only the project's own channels, and don't connect a wallet to sites pushed in replies or copy-paste posts. If you lost money in this or any exploit, report it to the FBI at ic3.gov and to the FTC at reportfraud.ftc.gov, and file a report at blockint.ai with your addresses and transaction IDs. It's free, and anonymous reports are accepted.