Inflate, Burn, Repeat - How a Liquidity-Share Bug Drained Spartan Protocol for $30.5M

Spartan Protocol's SPARTA/WBNB liquidity pool was drained of $30.5 million after an attacker exploited flawed logic in how the protocol calculated liquidity shares when LP tokens were burned for withdrawal — a haul large enough to land the exploit in 6th place on the rekt leaderboard at the time.

The core weakness was that Spartan's share calculation read directly from the pool's live balance rather than a cached, trusted figure. That let an attacker temporarily inflate the pool's balance using a flash loan, burn a matching quantity of pool tokens against that inflated balance, and walk away with a far larger share of underlying assets than they had actually deposited.

The following sequence is drawn from Peckshield's root cause analysis of the incident:

1. The attacker opened with a flash loan of 10,000 WBNB, which would ultimately be repaid at the end along with a 260 WBNB fee.
2. They then swapped WBNB for SPARTA five separate times through the vulnerable Spartan pool. Each swap put in 1,913.172376149853767216 WBNB, returning, in order: 621,865.037751148871481851, 555,430.671213257613862228, 499,085.759047974016386321, 450,888.746328171070956525, and 409,342.991760515634291439 SPARTA.
3. Those five swaps yielded a combined 2,536,613.206101067206978364 SPARTA. Together with 11,853.332738790033677468 WBNB, this was deposited into the pool, minting 933,350.959891510782264802 SPT1-WBNB pool tokens.
4. The attacker then repeated the swap ten more times through the same pool, each time putting in 1,674.025829131122046314 WBNB and receiving, in sequence: 336,553.226646584413691711, 316,580.407937459884368081, 298,333.47575083824346321, 281,619.23694472865873995, 266,270.782888292437349121, 252,143.313661963544185874, 239,110.715943602161587616, 227,062.743086833745362627, 215,902.679301559370989883, and 205,545.395265586231012643 SPARTA — a combined total of 2,639,121.977427448690750716 SPARTA.
5. To inflate the pool's asset balance, the attacker then transferred in 21,632.147355962694186481 WBNB along with the entire 2,639,121.977427448690750716 SPARTA obtained in the previous step.
6. The 933,350.959891510782264802 pool tokens minted back in step 3 were then burned to withdraw liquidity. Because the pool's balance had just been artificially inflated, this burn returned 2,538,199.153113548855179986 SPARTA and 20,694.059368262615067224 WBNB — even though step 3 had only put in 11,853.332738790033677468 WBNB, leaving the attacker roughly 9,000 WBNB ahead purely from this step.
7. The assets added in step 4 were then supplied back into the pool, minting 1,414,010.159908048805295494 pool tokens, which were immediately burned again to extract 2,643,882.074112804607308497 SPARTA and 21,555.69728926154636986 WBNB.
8. This cycle of inflating the balance and burning against it was repeated to continue extracting value from the pool.
9. Finally, the attacker closed out by repaying the flash loan, returning 100,260 WBNB in total.

Peckshield attributed the root vulnerability to Spartan's calcLiquidityShare() function pulling from the pool's current, manipulable balance instead of relying on the cached figures held in baseAmountPooled and tokenAmountPooled — the correct calculation would have used those stored values rather than the live, spoofable balance.

The bulk of the stolen assets ended up sitting in a single wallet, 0x3b6e77722e2bbe97c1cfa337b42c0939aeb83671, holding roughly:

• 30.7k WBNB (about $18.9M)
• 4.6M SPARTA (about $7.8M at the time of the hack)
• 1.3M BUSD-T (about $1.3M)
• 23.2 BTCB (about $1.3M)
• 924k BUSD (about $0.9M)

To cash out, the attacker routed funds through 1inch (swapping tokens into BTCB or BETH), used Spartan itself to offload SPARTA, and used Nerve to convert BTCB and BETH into their Anyswap-bridged equivalents, ultimately withdrawing part of the profit that way. Slippage along the route ate into the total, cutting the realized proceeds down by about a third, to roughly 219.5 BTC (about $12.4M) and 3,311 ETH (about $9.7M).

Credit for the analysis goes to Igor Igamberdiev.

At its core, this was a fairly conventional case of a protocol copying existing code without fully accounting for edge cases in its own implementation. With BSC's flash-loan era in full swing and a wave of developers rapidly porting established Ethereum projects to the chain, this kind of opportunity for attackers is unlikely to be a one-off. Turning roughly $66 in transaction fees into a $30 million payday is a striking return on investment, and as of this writing neither CZ nor Binance had commented publicly on the incident.