Date: June 28, 2026
Chain: BNB Chain
Loss: 220.12 WBNB, about $121K at the time
Class: token burn logic that destroys tokens inside its own liquidity pool and then resyncs the pool's reserves
AIDC, a BNB Chain token marketed as "AI Data Credit," charged a 30% burn on every sell into its PancakeSwap V2 pool. On June 28, 2026, one transaction with more than 180 token transfers in it turned that burn against the pool itself and walked away with 220.12 WBNB, about $121,000 at the time.
PancakeSwap did exactly what it was built to do throughout. The flaw sat in AIDC's own code, which recorded the burn when a seller sold but didn't take the tokens from the seller, and later collected the debt by burning AIDC straight out of the liquidity pool and telling the pool to accept its new, smaller balance.
A PancakeSwap V2 pool prices two tokens against each other with a constant-product formula: the pool's balance of AIDC multiplied by its balance of WBNB stays constant across trades, so the scarcer AIDC gets inside the pool, the more WBNB each AIDC is worth. The pool keeps its own record of those balances, called reserves, and a public function named sync() overwrites the reserves with whatever the pool actually holds at that moment.
AIDC added a deflationary twist on top of ordinary transfers. According to SlowMist's alert and the Crypto Times write-up, the token's _sellTransfer() function recorded a 30% burn amount on each sell, and a separate function, _executeAccumulatedBurn(), settled the accumulated amount the next time a transfer that didn't involve the pair came through.
Two pieces of that design went wrong together. _sellTransfer() added to the burn total without deducting those tokens from the seller, so the seller kept everything the burn was meant to remove. When _executeAccumulatedBurn() later ran, it burned the accumulated amount from the PancakeSwap pair's AIDC balance and then called sync() on the pair, which locked the smaller balance in as the pool's new reserve.
The pool lost AIDC without losing any WBNB, so its pricing shifted in favor of anyone holding AIDC. Picture a shop where the cashier writes down what a customer owes but never charges them, and at closing time takes the missing amount out of the till instead. The till comes up short, the customer keeps the money, and the books say everything balanced.
A token's transfer logic should never change what a liquidity pool holds outside of a swap or a liquidity deposit or withdrawal, because the pool's prices are only as honest as its balances. A burn that targets the pair's address and is followed by sync() is a price control that anyone who can trigger it gets to use.
Crypto Times reports that the attack ran as a single atomic transaction containing more than 180 BEP-20 transfers. The DeFiHackLabs reproduction of that transaction shows how the pieces fit. It borrows 200 WBNB in a flash loan from a PancakeSwap V3 pool and splits it between adding liquidity to the AIDC/WBNB pair and buying AIDC. Then it runs thirteen rounds, and in each one it deploys a brand new helper contract, hands it AIDC and has it sell into the pair. A comment in the PoC explains the choice: fresh sellers get around AIDC's per-address cooldown, while every sell adds to the burn debt that the next ordinary transfer settles out of the pair's balance. After the last round the remaining AIDC is sold for BNB, the flash loan is repaid, and the profit goes to the attacker. DeFiHackLabs puts the total at about 220.13 WBNB, in line with SlowMist's 220.12 WBNB.
The attacker used newly created wallets, moved funds through transit addresses and consolidated the 220 WBNB into the wallet that had originally funded the operation, according to Crypto Times. SlowMist valued the loss at about $120,929 and TenArmor at about $121,100, with the gap coming from the BNB price each used.
TenArmor flagged the attack at 02:10 UTC on June 29, and SlowMist's alert with the root cause followed at 03:35 UTC. Neither Crypto Times nor the other reports covering the incident mention a response from the AIDC team, a fix, or a compensation plan.
The class isn't new on BNB Chain. In February 2026, the LAXO token lost about $190K when its _transfer function burned tokens from its liquidity pair and called sync() before the seller's tokens reached the pool. AIDC deferred its burn and let the debt accumulate, but the step that moved the price was the same burn from the pair followed by sync().
Olympix reads a token contract the way an attacker does, as states, transitions and entry points, and takes in the context around it, here a token built to trade in a constant-product pool. The state that matters most is the pair's AIDC balance, and the engine maps every path that can change it. A signal is a pattern that marks a path as dangerous, and Olympix's static analysis surfaces the one in this contract: a burn whose target is the AMM pair's address, followed by a sync() call on that same pair, inside the token's own transfer logic. That narrows the search from every transfer path to the handful that can move pool reserves outside of a swap.
From there BugPoCer takes the token and the pair together as one system and asks what has to stay true between them. The answer it infers is that the pair's AIDC reserve moves only through swaps and liquidity operations, never as a side effect of someone else's transfer. Running Counterexample-Guided Invariant Refutation, it then executes paths through the token's transfer logic, working outward from that rule until one breaks it, and a sell that leaves the seller's balance untouched followed by any ordinary transfer that triggers _executeAccumulatedBurn() breaks it.
The result is a counterexample rather than a warning: the sequence of sells that builds the burn debt, the transfer that triggers the burn from the pair, the sync() that locks in the reserve, and the swap that pulls out WBNB at the distorted price, along with the minimal conditions and a generated Forge test that replays it. That's the June 28 drain, produced in development. Olympix has flagged this class before in other codebases, and when Olympix ran BugPoCer on LAXO after that exploit, it returned the vulnerability with a working proof of concept on a BSC fork.
Because Olympix runs automatically in development, at every merge and before release, a change to how a token's tax or burn settles gets the same treatment the day it's written, with the pool's reserves treated as part of the system the token has to protect.
Deflationary tokens can burn safely, as long as the burn comes from the seller, a treasury, or any balance other than the pool's. AIDC's numbers were small next to bigger incidents, but the mechanism is the one that turns a token's own tax logic into a lever on its liquidity, and it can be caught from the code alone before the first sell. If your token has custom transfer, tax or burn logic that touches an AMM pair, book a technical walkthrough.
Protocol: AIDC (AI Data Credit) token
Chain: BNB Chain
Date: June 28, 2026, 19:35:53 UTC
Loss: 220.12 WBNB (about $120,929 per SlowMist)
Attacker: 0x89eb...6b63
Attack contract: 0x26F6...1DE4
AIDC token contract (vulnerable): 0x5021...C6fe
Drained pool (AIDC/WBNB PancakeSwap V2 pair): 0x2725...cbd8
Exploit tx: 0x6696...645e
Block: 106926104
DeFiHackLabs: AIDC exploit PoC
Crypto Times: AIDC Token Burn Bug Exploit Drains $121K From PancakeSwap