This is a lower bound: only assets with reliable historical USD prices are counted, so the actual loss may be higher.
0x94055664287a565d4867a97ba6d5d2e28c55d10846e3f83355ba84bd1b9280fc0xa45d4359246dbd523ab690bef01da06b07450030BSC0x68e465a8e65521631f36404d9fb0a6fad62a3b37BSCOn BNB Chain block 37740233, attacker EOA 0xc1b6f9898576d722dbf604aaa452cfea3a639c59 called attacker contract 0xb22cf0e1672344f23f3126fbd35f856e961fd780, which spawned fresh helper contracts, funded them with USDT, bought BBG on PancakeSwap, and repeatedly invoked sellRewardToken(uint256) on BigBangSwap proxy 0xa45d4359246dbd523ab690bef01da06b07450030. Each helper realized USDT, swept it back to the orchestrator, and the seed transaction ended with a net gain of 4718415739501433390601 USDT units for the attacker contract.
The root cause is a public reward-sale path that consumes protocol-owned liquidity while enforcing release accounting only per msg.sender. Because the cap is keyed to the current caller address, a fresh helper contract is treated as a fresh quota, so any unprivileged actor can repeat the flow until the pair liquidity is drained or the contract's internal liquidity guard reverts.
At the exploit block, proxy 0xa45d4359246dbd523ab690bef01da06b07450030 resolved through its EIP-1967 implementation slot to implementation 0x6ef66fd568903c072a9654e2c8db9520686932cf. Collected storage decoding shows router slot 0xd2 pointing to 0xb0b28416c6c84041d93841aec59ed163fc03d8a3, pair slot 0xd4 pointing to 0x68e465a8e65521631f36404d9fb0a6fad62a3b37, staking token slot pointing to USDT , and reward token slot pointing to BBG .
0xd50x55d398326f99059ff775485246999027b31979550xd60xac4d2f229a3499f7e4e90a5932758a6829d69cffThe external market needed for exploitation was permissionless. PancakeSwap pair 0x218674fc1df16b5d4f0227a59a2796f13febc5f2 allowed any caller to buy BBG using USDT, and BigBangSwap pair 0x68e465a8e65521631f36404d9fb0a6fad62a3b37 held meaningful USDT and BBG reserves plus LP inventory owned by the proxy. The exploit therefore required no privileged key material, no private attacker bytecode reuse, and no special access beyond normal transaction inclusion.
The vulnerable component is sellRewardToken(uint256) on implementation 0x6ef66fd568903c072a9654e2c8db9520686932cf, reached through the proxy. Selector collection confirms that the implementation exposes sellRewardToken(uint256), claimRewards(address), setRewardOperator(address,bool), and isRewardOperator(address). The decompiled execution path for sellRewardToken(uint256) does not perform an ownership or reward-operator authorization check before moving attacker-supplied BBG into the proxy and consuming protocol-owned LP-backed liquidity.
The relevant safety invariant is: only protocol-authorized reward inventory should be convertible into protocol-owned pair liquidity, and any release cap must bind to the economic actor rather than reset on each new helper address. The first invariant-breaking breakpoint occurs in the sellRewardToken(uint256) path around 0x0ca1-0x10d8, where the function accepts arbitrary caller BBG, derives storage keys from CALLER, and then routes through the BigBangSwap router/pair liquidity removal path.
The issue is therefore not a pricing anomaly or a one-off edge case. It is a deterministic authorization and accounting flaw: caller-scoped release tracking can be bypassed by spawning fresh contracts, and the public function spends protocol-owned liquidity in response to arbitrary external input.
The implementation dispatch table includes the public entrypoint:
0xba531b6d sellRewardToken(uint256)
0x7aafb332 setRewardOperator(address,bool)
0x99d41ca6 isRewardOperator(address)
0xef5cfb8c claimRewards(address)
Inside the sellRewardToken(uint256) path, the disassembly shows the function pulling BBG from the current caller and then computing reward-accounting storage keys from CALLER:
00000cf4: CALLER
00000cf5: PUSH2 0x32a0
...
00000e55: JUMPDEST
00000e56: CALLER
...
00000e60: KECCAK256
...
00000e8b: CALLER
...
000010b9: CALLER
000010d1: LOG1
The same path also consumes protocol liquidity rather than user-owned liquidity. In the validator-reviewed auditor forge trace, a helper buys BBG, approves the proxy, calls BigBangProxy::sellRewardToken, transfers BBG into the proxy, and then drives BigBangRouter::removeLiquidity plus BigBangPair::burn:
helper_one::go()
PancakeRouter::swapExactTokensForTokensSupportingFeeOnTransferTokens(...)
BigBangProxy::sellRewardToken(288417824350561936138)
BBG::transferFrom(helper_one, BigBangProxy, 288417824350561936138)
BigBangRouter::removeLiquidity(BBG, USDT, 432735741962902299305, 1, 1, BigBangProxy, ...)
BigBangPair::burn(BigBangProxy)
The seed attack trace shows the same sequence on-chain for real attacker helper contracts. Helper contract 0xab3d2f2d70deb75ac948f8f8a7136d0f90487cfe is called by orchestrator 0xb22cf0e1672344f23f3126fbd35f856e961fd780, then interacts with Pancake router 0x10ed43c718714eb63d5aa57b78b54704e256024e, approves BBG to the proxy, and calls proxy 0xa45d4359246dbd523ab690bef01da06b07450030. The public exploit conditions are therefore complete:
sellRewardToken(uint256) from a fresh helper address.Because the release accounting is keyed to msg.sender, step 3 resets the cap every time the attacker deploys a new helper. That is the mechanism that turns a caller-scoped reward release into an ACT drain.
The seed transaction 0x94055664287a565d4867a97ba6d5d2e28c55d10846e3f83355ba84bd1b9280fc was submitted by EOA 0xc1b6f9898576d722dbf604aaa452cfea3a639c59 to attacker contract 0xb22cf0e1672344f23f3126fbd35f856e961fd780. The orchestrator funded helper contracts with USDT, and a traced helper 0xab3d2f2d70deb75ac948f8f8a7136d0f90487cfe executed the buy-and-drain cycle. Earlier-success traces show the same pattern for helpers 0x1D3F169eF7A17369E97f8060F624DC408958142A and 0x7f4EF02101CDEA64e758CB8a8f5723b1Ba93EF28.
The on-chain sequence is:
sellRewardToken(uint256).This is a single-transaction, multi-helper campaign. The exploit does not require frontrunning a victim transaction; it only requires the vulnerable implementation to remain live and the pair to still hold enough liquidity for each helper call.
The seed transaction balance-diff artifact quantifies the impact. Attacker contract 0xb22cf0e1672344f23f3126fbd35f856e961fd780 increased its USDT balance from 14586023105368246444357 to 19304438844869679834958, a net gain of 4718415739501433390601 USDT units. Over the same transaction:
0x68e465a8e65521631f36404d9fb0a6fad62a3b37 lost 6972319699838365285126 USDT units.32129312503023821010833 BBG units.0xa45d4359246dbd523ab690bef01da06b07450030 lost 33767699479489883855801 LP units.These losses show that the attacker profit came from depletion of protocol-controlled liquidity, not from a neutral arbitrage cycle.
0x94055664287a565d4867a97ba6d5d2e28c55d10846e3f83355ba84bd1b9280fc0xc1b6f9898576d722dbf604aaa452cfea3a639c590xb22cf0e1672344f23f3126fbd35f856e961fd7800xab3d2f2d70deb75ac948f8f8a7136d0f90487cfe0xa45d4359246dbd523ab690bef01da06b074500300x6ef66fd568903c072a9654e2c8db9520686932cf0x68e465a8e65521631f36404d9fb0a6fad62a3b370xb0b28416c6c84041d93841aec59ed163fc03d8a30x218674fc1df16b5d4f0227a59a2796f13febc5f237740233, implementation selector list, and implementation disassembly.