AIDC exploit analysis

AIDCToken's transfer hook burned a portion of any transfer's sender balance directly out of the recipient whenever the sender's most recent batch had routed through a PancakeSwap V2 pair to the recipient side. Repeated fresh sell burns in the same block could therefore shrink the AIDC/WBNB pair's recorded reserve while leaving the actual ERC-20 balance higher, and a sync() after the burn sequence pinned the pair at the deflated ratio. A router swap against the wrecked ratio then drained the pair's WBNB in proportion to the deflation.

The attacker at 0x89eb2c99e970d831525c7a52badc290afa116b63 flashed 200 WBNB through Pancake V3 to seed the loop, kicked off the fresh-helper sell loop that exited cheap AIDC through the pair (13 iterations per the PoC), then triggered the pair's burn with a router transfer and called sync() to lock the deflated AIDC reserve. The remaining AIDC was swapped back to WBNB at the inflated AIDC-rare ratio and 1 ETH was forwarded to the builder-tip address.

DeFiHackLabs reports a total loss of about 220.13 WBNB. The drain is in 0x66960f7febf399fa8bd94904398f535c500f4f575dbf025de7b9ab450342645e on BscScan. The vulnerable AIDC contract is 0x5021d71859f81b4c905b573591db8f9cc4a0c6fe; the pair is 0x2725033282b3bd4BE8873B7F0f622c18E3b7cbd8.

What would have prevented it: a transfer hook that only burns from the sender, not from the AMM pair. Or a token's transfer-tax hook that cannot route its burn through pool reserves at all - i.e., an exclusion list that always treats the AMM pair as exempt from the burn side.