On June 17, 2026, the BNB Chain DeFi project DIP Protocol was drained of an estimated $111,000, according to initial incident reports. The attacker reportedly abused a flaw in how the protocol accounted for pool reserves during token transfers — a skim-style routine that could be made to double-count reserves, letting the attacker withdraw more value than they were entitled to.

We are still verifying the on-chain specifics (transaction hashes and the attacker address) against block-explorer data and will update this page with the confirmed trail. What follows is an explanation of the class of vulnerability, which is well understood and recurs across automated-market-maker (AMM) style contracts.

What a “reserve skim” bug actually is

AMM pools track internal reserves — the contract’s own record of how many tokens it holds. Many pools also expose a skim() function: a maintenance routine that pushes out any tokens sent to the contract above the recorded reserves, so the accounting stays consistent.

The danger appears when the balance check and the reserve update get out of sync. If a router or transfer path lets a caller trigger an accounting update before the contract reconciles its true token balance, the same surplus can be counted twice — once by the pool’s internal math and once by the attacker who skims it out. Repeat that in a loop and the pool bleeds value with every iteration.

This is a cousin of the classic re-entrancy and fee-on-transfer mismatch bugs: the contract trusts a number it should have re-derived from balanceOf at the moment of truth.

Why it keeps happening

Three recurring reasons:

  • Composability. Pools are called by routers, which are called by aggregators. Each hop is an opportunity for the reserve and the real balance to diverge.
  • Fee-on-transfer and rebasing tokens. Any token whose transferred amount differs from the requested amount breaks naive reserve math unless the contract measures balances before and after.
  • Copy-paste forks. A subtle fix in an upstream AMM often never reaches the dozens of forks that inherited the original bug.

How protocols defend against it

  • Measure, don’t assume. Re-read balanceOf(address(this)) and compute deltas at the moment of settlement rather than trusting cached reserves.
  • Check-effects-interactions and re-entrancy guards on every state-changing path, including skim and sync.
  • Invariant tests and fuzzing that assert reserves can never exceed real balances after any sequence of calls.
  • Independent audits plus a live bug bounty sized to the TVL at risk — a five-figure bounty rarely outbids a six-figure exploit.

What to watch next

The immediate questions are whether DIP Protocol can negotiate a return of funds (increasingly common via on-chain messages to the attacker), whether a single audited dependency is implicated, and whether other forks of the same pool code are exposed. We will track the attacker address once confirmed and update the incident facts above.

Have details on this incident, including transaction hashes or the official post-mortem? Reach the desk via @mrtdnet on Telegram.