BOSS Token's $10.2K Loss and How Olympix Would Have Prevented It

Loss

Exploit date

June 6, 2026

Date: June 6, 2026

Chain: BNB Chain

Loss: 10,207.54 USDT

Class: a public helper path that could burn the pool's own tokens and resync its reserves

The BOSS/USDT pool on PancakeSwap held about 10,215 USDT on the afternoon of June 6, 2026. At 15:28:06 UTC, one transaction borrowed 1.25 million USDT, pushed it through BOSS's own helper contract and the pool, and handed every borrowed dollar back before it ended. When it was over, the pool had 7.45 USDT left and the attacker's wallet held 10,207.54 USDT that had belonged to the pool's liquidity.

The attacker never needed to break a permission. BOSS kept its most dangerous functions, minting new BOSS and burning BOSS out of an address, restricted to one trusted caller. The trouble was that the trusted caller would do those things on behalf of anyone who asked through the right public function.

A Token That Managed Its Own Pool

BOSS is a BNB Chain token paired with USDT in a PancakeSwap V2 pool. Like a lot of tokens built around their own liquidity, it doesn't leave the pool alone. A helper contract exposes public business functions, userMint, userBurn and sell, and those functions route through a pool-management address that can call BOSS.mint() and BOSS.burn(pair, amount). Mint and burn are restricted to that address, which on paper keeps them out of reach.

According to audit911, the public helper functions reach those restricted calls indirectly, and the burn path calls pair.sync() right after burning. A burn that removes BOSS from the pair's balance followed by an immediate sync rewrites the pool's recorded BOSS reserve to whatever is left. Uniswap V2-style pools price every swap from those recorded reserves, so whoever controls when that burn and sync happen controls the pool's price.

The Order of Operations

audit911's analysis lays out why the timing mattered. An attacker could read BOSS's price through getPrice() at the old reserves, then have the BOSS side of the BOSS/USDT pool burned almost to zero and that broken middle state synced into the pool as its new reserves. After the sync, the pool's books said it held a large amount of USDT against almost no BOSS, and a pool in that state will pay out a large amount of USDT for a tiny amount of BOSS.

Every step in that chain was code doing what it was written to do. The helper's functions were public on purpose, because ordinary users mint and sell through them. The burn was restricted on purpose, and the restriction held. What nobody had pinned down was what a public caller could make the restricted caller do to the pair, and in what order.

Inside the Transaction

The DeFiHackLabs reproduction and the on-chain logs show the attack in one transaction, sent by the attacker's wallet 0x6186...2C91 to its contract 0x6a37...803D.

The contract borrowed 1,250,000 USDT through a Moolah flash loan. It sent 100,000 USDT into the helper's userMint, which minted BOSS and added it with the USDT to the pool, and then swapped the remaining 1,150,000 USDT for BOSS through the PancakeSwap router. At that point the pool held roughly 1.26 million USDT, almost all of it the attacker's borrowed money.

Next came the helper's burn path. The logs show 855,488 BOSS leaving the pair to the zero address and a sync that recorded the pair's BOSS reserve as effectively nothing, against about 700,898 USDT. DeFiHackLabs describes this as calling userBurn on the helper to burn the pair's BOSS down to a dust balance.

From there the contract only had to sell. DeFiHackLabs' reproduction runs 155 small sells, each sending a slice of BOSS into the pair and taking USDT out at the broken ratio, and on-chain the pool's USDT reserve fell sell by sell until 7.45 USDT remained. The contract repaid the 1,250,000 USDT loan and forwarded the remaining 10,207.54 USDT to the attacker's wallet. On-chain, the pair paid out 1,260,207.54 USDT across the transaction and received 1,250,000, a net loss of exactly 10,207.54 USDT, the same figure DeFiHackLabs records.

As of November 6, 2026, we found no public statement or post-mortem from the BOSS team.

A Familiar Shape on BNB Chain

Tokens that burn from their own pair and resync have produced a steady run of incidents this year. SKYDAO lost $183K in September when its sell tax let a pool controller burn the pair's SKYDAO and sync the pool's books mid-sell, and BOSS's version arrived through a helper instead of a tax hook.

How Olympix Would Have Broken the Pool Invariant in Development

Olympix reads a protocol as states, transitions and entry points, and it reads the token, the helper and the pair together, because that's where this bug lives. The state that matters is the pair's reserves. The entry points are the helper's public functions. The transitions run through the pool-management address into BOSS.mint, BOSS.burn and pair.sync.

The invariant follows from how a constant-product pool is supposed to work: the pool's reserves should only change through trades and liquidity actions that pay for what they take, so no sequence of calls should let an outside caller pull USDT out of the pool without putting in matching value. BOSS's restricted burn looked safe in isolation, but restriction only governs who makes the call. The invariant is about what any reachable path does to the reserves.

BugPoCer would have attacked that invariant directly. Counterexample-Guided Invariant Refutation works outward from the system as a whole, searching every path that reaches the pair's reserves for a sequence that ends with the pool poorer and the caller richer. Here the path runs through public functions only: deposit through userMint, buy BOSS, trigger the helper's burn so BOSS leaves the pair and the sync locks in the broken ratio, then sell small amounts of BOSS for USDT. BugPoCer would have returned that sequence as a counterexample with the minimal conditions it needs and a generated Forge test that replays it against a fork of the pool, which is the June 6 drain produced in development.

That counterexample is also the clearest way to scope a fix. It shows the exact public entry point that reaches the restricted burn and the exact point where the sync writes a state the pool should never accept, so the team can decide whether the helper should lose that path or whether the burn should never touch the pair's balance.

What the Restriction Didn't Cover

BOSS did restrict its mint and burn, and it restricted them to the right caller. The gap was in what that caller would do for others, and in a sync that turned a mid-transaction state into the pool's permanent price. Testing the pair, the token and the helper as one system is how that path turns into a test failure before release instead of a drained pool after it. To see how Olympix maps the paths into your own pools and returns a runnable counterexample for each one that breaks a reserve invariant, book a technical walkthrough.