Four exploits this week, $1.9M gone — and every dollar of it was preventable.
All four were textbook code-level bugs: a burn that let public skim and sync calls rewrite pool reserves, collateral priced off a spot rate an attacker can move in one transaction, a balance check that minted tokens out of nothing on zero-value transfers, a burn charged to the pool instead of the seller. None of them are novel. They're the same classes we watch drain funds week after week, and every one surfaces the moment you run proactive security tools against the contract, before it ever reaches mainnet.
That's the whole idea behind Olympix: catch the preventable class in the dev loop, so this kind of loss stays a line in a report instead of a headline.
On June 20, the OLPC/LABUBU exploit on BNB Chain drained 1,115,903.66 USDT (~$1.12M) from the LABUBU/OLPC PancakeSwap V2 pool. The root cause was a token-side flaw in OLPC: when the AMM pair is the transfer sender, OLPC’s `_updateTransfer()` treats the transfer as a buy, computes an amplified burn (`amount * _decimalsValue`), moves that amount from the pair to the dead address, and sets the delivered amount to 0.
Because PancakeSwap V2 `skim()` is public and forces the pair to transfer its surplus, the attacker looped dust transfers plus `skim(helper)` and `sync()`. Each skim made the pair send OLPC; OLPC then burned an amplified amount from the pair while delivering 0 to the recipient. Twenty `skim` and twenty-one `sync` calls moved ~51.93M OLPC from the pair to the dead address, collapsing the OLPC reserve to ~0.375 while LABUBU remained nearly unchanged.
The attacker then used the distorted fee-on-transfer swap path to release ~688,381 LABUBU, sold ~564,128 (after LABUBU’s sell tax) through LABUBU/WBNB and WBNB/USDT into ~2,041 WBNB, and ultimately cashed out to 1,115,903.66 USDT. This matches the DIP and LittleBoyPlus family: a token-side burn that lets pair-originated transfers rewrite reserves and drain the opposite side.
Attacker/Executor: 0x18d6c39ae9e537f948aa2212d44d8c23944fc188
Exploit Tx: 0x8dabb60a94e5124462e5f494a25c14bcd52f6f4d1f7c665a249496f4c6c24764
On July 1st, the Edel Finance exploit on Ethereum created approximately $403K in protocol bad debt across its lending markets. The root cause was manipulable collateral pricing. wGOOGLx collateral was valued off the wrapped xStocks exchange rate between wGOOGLx and GOOGLx, a spot read with no TWAP and no manipulation guard, so the attacker opened a 180,000 USDC flash loan from Morpho, manipulated that rate to value wGOOGLx at roughly 78x its correct value within a single transaction, and borrowed against the inflated collateral, leaving the protocol with bad debt.
The attacker consolidated the extracted tokens into 224 ETH and deposited into Tornado Cash. This is the oracle and spot-price manipulation family: a lending market that trusts a manipulable exchange rate instead of a manipulation-resistant feed.
Attacker: 0x58428161bB55c14A413945f06cbDeC157F411C76
Exploit Tx: 0xe2320086b2815d21b0927839bd0e306466c29a68d38d5361e99dd21ec5472612
On June 24th, the Royalties contract exploit on Polygon drained roughly $263K. The root cause was a balance-conservation flaw in the Royal1155LD.beforeLdaTransfer() hook.
When _IS_OWNED_TOKENS_BACKFILL_COMPLETE_ was true and the transferred balance == 0, the hook skipped the from balance update while still incrementing the to balance by 1, so a zero-value transfer that should net to nothing instead credited the receiver free balance out of the accounting gap. The attacker sent 100 zero-value transfers, each one adding balance with no corresponding debit, stacking the position and the reward records that key off it, then claimed the inflated claimable and drained $263K. A transfer must conserve total balance, and the balance == 0 branch updated only one side of the move.
Vulnerable Contract (Royal1155LD / Royalties): 0xfE16Ee78828672e86cf8E42d8A5119AB79877EC7
On June 28th, the AIDC token exploit on BSC drained 220.12 WBNB (about $120.9K) from the AIDC/WBNB PancakeSwap V2 pair. The root cause was a burn-accounting flaw in AIDC's own contract that charged the burn to the wrong account.
On a sell, `_sellTransfer()` accrued a 30% burn amount but never deducted it from the seller, creating a burn debt with no source. Any following non-Pair transfer then triggered `_executeAccumulatedBurn()`, which burned that accrued amount from the `uniswapPair` balance rather than the seller, and called `sync()`. Burning the pair's tokens and syncing deflated the AIDC reserve in the AMM, and the attacker repeated that sequence to manipulate the reserve, then swapped to drain the WBNB. The seller incurred the debt and the pool paid it, which is the token-side flaw that broke the pair's accounting. This is the reserve-manipulation-via-token-logic family, alongside DIP, LittleBoyPlus, and OLPC.
Attacker: 0x89eb2c99e970d831525c7a52badc290afa116b63
Exploit Tx: 0x66960f7febf399fa8bd94904398f535c500f4f575dbf025de7b9ab450342645e