Date: June 5, 2026
Chain: BNB Chain
Loss: about 35,041 USDT
Class: fee logic that trusts a pair balance anyone can change
On June 5, 2026, someone sent 1 wei of USDT, the smallest unit the token has, straight to the DTXT/USDT pair on PancakeSwap. An amount that small is worth far less than a cent, and it was still enough to change how the DTXT token read the very next trade.
In the same transaction, the attacker sold a large block of DTXT into the pair, paid none of the sell fee, and walked away with about 35,041 USDT out of a pool that held roughly 35,637. DTXT decided whether a transfer was a sell or a liquidity deposit by comparing two numbers inside the pair, and one of those numbers could be moved by anybody who sent the pair a token.
DTXT is a fee-on-transfer token on BNB Chain. According to the crypto.training reproduction of the exploit, the token takes a 5% destroy and dividend fee when tokens are sold into its PancakeSwap pair. Fees like this are common on BNB Chain tokens, and so is the exemption that goes with them: people adding liquidity to the pool shouldn't pay the sell fee, since they're supporting the market instead of exiting it.
That exemption creates a classification problem. From inside the token contract, a sell and a liquidity deposit look much the same, because in both cases DTXT is moving into the pair address. The contract needs some way to tell them apart, and whatever it uses becomes the line between paying 5% and paying nothing.
A PancakeSwap V2 pair keeps two records of what it holds. The reserve is the number the pair stored the last time it updated its books, and the balance is what the token contract says the pair actually owns right now. Most of the time they match. When someone adds liquidity through the router, the second token lands in the pair just before the pair updates its reserves, so for a brief moment the live USDT balance is higher than the stored USDT reserve.
DTXT used that moment as its signal. SlowMist's analysis, reported by Foresight News, says the contract determined whether an operation was a sell or a liquidity addition by comparing the pair's USDT balance with its USDT reserve. If the balance was higher, the transfer counted as a liquidity add and the fee was skipped.
The catch is that a pair has no say over who sends it tokens. Anyone can transfer USDT directly to the pair address at any time, and the pair won't fold that USDT into its reserve until something triggers an update. A single direct transfer opens exactly the gap DTXT treated as proof of a liquidity deposit.
The lesson for builders fits in one sentence: any value an outsider can change for the cost of a transfer is an input, and code that grants an exemption based on it has handed that exemption to everyone. It's a bit like a parking garage that waives the fee for any car whose dashboard shows a staff badge, when anyone can print one.
The attack ran in a single transaction funded by a flash loan, a loan that's borrowed and repaid inside one transaction. The attacker borrowed about 1.0774 million USDT from Moolah, a lending protocol on BNB Chain, according to the Foresight News report. The DeFiHackLabs proof of concept reconstructs what happened inside that loan and names the contracts involved: the DTXT token at 0xAc9B...97D2 and its PancakeSwap pair at 0x90Bf...6c01.
First, the borrowed USDT went into the pool alongside DTXT held by a helper contract the attacker had funded beforehand, minting liquidity tokens, and the attacker immediately removed that liquidity again, keeping the DTXT that came back out. Then came the step that mattered. The attack contract sent 1 wei of USDT directly to the pair, which pushed the pair's live USDT balance above its stored reserve, and right after that it transferred its whole DTXT balance into the pair. When DTXT's transfer logic ran its check, it saw a USDT balance higher than the reserve, classified the transfer as a liquidity addition, and let the full amount through without the 5% fee.
With the untaxed DTXT sitting in the pair and the reserves still showing the old numbers, the attack contract called the pair's swap function directly and took out the USDT that amount of DTXT was worth. crypto.training's reproduction describes the result as a fee-free sell against stale reserves, which drained about 35,041.11 USDT from a pair that held roughly 35,637 USDT. The flash loan was repaid in the same transaction, and the remaining USDT went to the attacker's wallet at 0xd304...9526, per the proof of concept and SlowMist's alert.
Olympix reads a token the way an attacker would, as a set of states, transitions and entry points. For DTXT, the state that matters is how much fee each transfer into the pair pays, and the transitions that change it are the branches inside the transfer logic that decide between "sell" and "liquidity add". The engine also takes in the context around the code, including the token's own fee design, to infer the rules the system depends on but never writes down.
A token's possible paths look endless, but the engine maps them and uses signals to decide which ones deserve an attack. The signal here is a fee exemption whose condition reads the pair's live token balance, a value that any address can raise by sending tokens to the pair. That narrows the search from every transfer path to the feasible ones that touch the fee branch, and then to the single comparison that decides whether 5% gets taken.
The invariant in plain words is that every sale of DTXT into the pair pays the sell fee, whatever the pair's balance looked like beforehand. The engine attacks a flagged path from two directions. Counterexample-Guided Invariant Refutation works from the system outward, inferring that rule and executing paths until one breaks it, and Bounded Adversarial Verification works from the signal inward, running known attack strategies such as a direct donation to the pair. Either way, the output is a counterexample: a direct USDT transfer to the pair followed by a large DTXT sell that pays no fee, with the minimal conditions that trigger it and a generated Forge test that replays it. That's the June 5 attack, produced in development instead of on BNB Chain.
Because this runs automatically during development, at every merge and before release, a team shipping a fee token gets a standing view of which branches its exemptions really depend on, alongside whatever audit coverage it has.
DTXT's fee rule was reasonable on its face, and the comparison it relied on does behave correctly for honest liquidity providers. It fell apart because the condition for skipping the fee was something an outsider could set for 1 wei. Fee tokens that exempt liquidity adds are safer when the exemption depends on who is calling, such as the router or an allowlisted address, and when someone has actually tested what happens if the pair's balance is moved first. To see how Olympix finds the counterexample hiding in your own fee logic before a pool does, book a technical walkthrough.
Protocol: DTXT (fee-on-transfer token)
Chain: BNB Chain
Date: June 5, 2026, 09:28:06 UTC
Loss: 35,041.11 USDT from the DTXT/USDT PancakeSwap pair (pool held roughly 35,637 USDT)
Flash loan: about 1.0774M USDT from Moolah (0x8F73...5D8C)
Attacker EOA: 0xd304...9526
Attack contract: 0x3065...5f5f
Pre-funded DTXT helper: 0xd245...5428
DTXT token (vulnerable contract): 0xAc9B...97D2
DTXT/USDT PancakeSwap pair: 0x90Bf...6c01
Exploit tx: 0x07ba...671d
Block: 102432240
SlowMist: DTXT/USDT pair exploit alert
DeFiHackLabs: DTXT liquidity misclassification fee bypass PoC
Foresight News via Bitget: DTXT/USDT trading pair attacked, about 35,000 USDT lost