Balancer V2 Rounding Exploit: $128M Drained in 30 Minutes

At 07:48 UTC on November 3, 2025, an attacker began draining Balancer's V2 Composable Stable Pools across Ethereum, Arbitrum, Base, Berachain, Optimism, Polygon, and Sonic — extracting $128.64 million in total before the protocol could pause affected contracts. The exploit required no flash loan coordination, no governance manipulation, and no oracle attack: it weaponised a rounding error in Balancer's swap calculation logic that had been present in the codebase since V2 launched in 2021 and that 11 security audits by four separate firms had failed to surface. Builders who run liquidity on any Balancer V2 fork need to understand exactly what failed and why.

What the Balancer V2 Rounding Exploit Was and Who Was Affected

The targeted contracts were Balancer V2 Composable Stable Pools — a specific pool type that uses a mathematically stable invariant (similar to Curve's StableSwap) to maintain near-peg pricing between correlated assets like liquid-staking tokens. According to Check Point Research's post-incident blockchain analysis published November 5, 2025, the attacker deployed exploit contract 0x54B53503c0e2173Df29f8da735fBd45Ee8aBa30d with a three-address operational structure, and executed the full drain during contract deployment — the constructor ran the exploit code automatically.

The Ethereum deployment suffered $99 million in losses. Arbitrum, Base, Berachain, Optimism, Polygon, and Sonic absorbed the remaining $29 million. According to on-chain data published by DappRadar, Balancer's total value locked (TVL) dropped approximately 46% across every supported chain within 24 hours of the exploit, falling from over $626 million to approximately $338 million. The exploited assets included WETH, osETH (StakeWise's liquid staking token), and wstETH.

Balancer V3 was not affected. The exploit vector was specific to V2 ComposableStablePool contracts. Forks of Balancer V2 — including Beets Finance on Sonic — reported secondary losses exceeding $3 million from the same vulnerability. Berachain's validator set executed an emergency network hard fork to recover funds linked to a Balancer-adjacent exploit on BEX, its native exchange.

Check Point Research: full technical analysis of the Balancer exploit

The Technical Vector: How a Rounding Error Became $128 Million

The vulnerability lived in the _upscaleArray function within Balancer V2's pool math. This function uses mulDown — a multiply-then-round-down operation — to scale token amounts during swap calculations. In normal operation, the precision loss from a single mulDown call is negligible: fractions of a wei. But the invariant value D that governs pool pricing is calculated from these scaled token balances, and any underestimation of token amounts produces a corresponding underestimation of D.

The attacker's methodology, as confirmed by Check Point Research and independently by Trail of Bits, exploited the compounding effect of batch operations. The batchSwap function allows multiple swap operations within a single atomic transaction. The attacker constructed batchSwap calls containing 65 sequential micro-swaps, each targeting token balances at a critical threshold — approximately 8 to 9 wei — where rounding errors in _upscaleArray were maximised.

Within each batchSwap call, the attack executed a three-stage cycle. First, large amounts of Balancer Pool Token (BPT) were swapped for underlying tokens to push one token's balance to the 8–9 wei threshold. Second, a small swap was executed involving the boundary-positioned token, causing _upscaleArray to underestimate the invariant D and artificially suppress BPT price. Third, the attacker purchased BPT at the suppressed price and immediately redeemed it for underlying assets at full value. All 65 cycles ran atomically within one transaction, preventing any intermediate intervention.

According to Trail of Bits — which had conducted three security reviews of Balancer V2 between 2021 and 2023 — the initial 2021 audit identified rounding and precision-related issues and included a full appendix on precision management. However, the specific compound effect of adversarial batchSwap operations at boundary-threshold balances was not modelled. The gap, as Trail of Bits explained in its November 7 post-incident analysis, was that traditional testing validates individual operation correctness, not cumulative effects of crafted adversarial batch sequences.

Trail of Bits post-incident analysis and DeFi security guidance

Eleven Audits, One Missed Vector: What the Audit Paradox Reveals

The Balancer V2 exploit exposed a structural limitation in how the DeFi industry conducts security reviews. According to the post-incident analysis from Halborn Security, Balancer V2 had been audited by four security firms across 11 separate engagements. Yet the _upscaleArray rounding error persisted in production from launch in 2021 until November 2025 — more than four years.

The audit paradox here is specific: individual function correctness is what standard audit methodologies verify. Auditors confirmed that each mulDown operation rounded correctly, that each individual swap returned valid outputs, and that the pool invariant calculations met specification at the function level. None of these checks were wrong. The vulnerability only became exploitable when adversarial batch operations compounded individually-correct rounding errors 65 times within a single atomic transaction.

Trail of Bits identified the fix: DeFi protocols must document every invariant pertaining to precision loss and rounding direction, then defend each with either a formal proof or fuzz campaign. The canonical invariant — "rounding must favour the protocol" — is insufficient to capture edge cases in multi-operation user flows. Trail of Bits' post-incident guidance references its Echidna and Medusa fuzzers as the most effective tools for this class of invariant validation, because fuzzing can generate adversarial input sequences that humans and traditional unit test suites do not model.

A secondary threat emerged following the breach: opportunistic phishing campaigns impersonating Balancer security staff offered fake "white-hat bounties" of 20% to the attacker in exchange for returning the remainder. Balancer warned users explicitly that these communications did not originate from the team. Builders operating on Balancer V2 forks also need to account for this social engineering layer — public exploits consistently produce secondary phishing attempts targeting users attempting to withdraw funds.

Web3 Fraud Files: DeFi exploit case archive→ /categories/web3-fraud-files

What Recovery Looks Like: $27.7 Million From $128 Million Lost

Three weeks after the breach, Balancer DAO published a governance proposal to distribute $27.7 million in recovered assets to affected users, according to the Cryptobreaking analysis from November 28, 2025. Recovery came through two streams. An $8 million tranche recovered through white-hat interventions and internal efforts was to be distributed proportionally to Balancer Pool Token (BPT) holders in the directly affected pools. A separate $19.7 million tranche, recovered primarily by liquid-staking partner StakeWise (covering osETH and osGNO), was to be forwarded independently by StakeWise to its affected users.

The combined $27.7 million represents approximately 22% of total losses. Balancer's DAO explicitly structured the distribution as non-socialised: losses are not spread across the broader protocol's LPs, only to those who held BPT positions in the exploited pools at the time of the attack.

For builders running on Balancer V2 forks, this recovery structure sets a precedent — but also a stark benchmark. Approximately 78% of stolen assets were not recovered. The Chainalysis 2026 Crypto Crime Report noted that North Korean state-affiliated groups (specifically the Lazarus Group) were responsible for over $2 billion in crypto theft during 2025. While no attribution was made for the Balancer exploit, Check Point Research noted that the scale and multi-chain coordination method were consistent with patterns seen in state-sponsored attacks — though no technical indicators such as reused contract code or wallet clustering confirmed this.

DeFi infrastructure builder security considerations→ /categories/web3-builder

Builder Decision Framework: Forked Balancer V2 Risk Assessment

Builders operating protocols forked from Balancer V2 face a clear-cut decision: treat the V2 ComposableStablePool contracts as undeployable until a post-exploit patch has been independently verified, or migrate liquidity to Balancer V3, which Trail of Bits independently confirmed was not affected by this vulnerability.

The practical steps are: first, verify which pool type your fork uses — ComposableStablePool contracts are the specific affected type, not WeightedPool or other V2 variants. Second, check whether your fork has introduced any modifications to the _upscaleArray function or its callers since the original Balancer V2 deployment. Third, engage a fuzzing campaign specifically against adversarial batchSwap sequences at boundary-threshold balances before any further liquidity deployment.

For builders considering new DeFi protocol development, the Balancer exploit offers a direct mandate: document all precision-loss invariants at the system level before audit, not during. As Trail of Bits stated in its post-incident summary, invariant testing must model cumulative adversarial batch operations — not just individual function correctness. Formal verification of the most critical invariants, particularly those involving cumulative arithmetic across shared pool state, should accompany fuzzing rather than replace it.

Halborn Security: Balancer V2 exploit explained

Balancer's next governance signal for external operators is whether the DAO follows through on the $27.7 million recovery distribution and publishes a full technical post-mortem — as of the November 2025 period, the Balancer team confirmed forensic investigation was ongoing with blockchain analytics partners. The Balancer V3 migration path, confirmed unaffected by this exploit vector, represents the defined upgrade target for any liquidity provider or protocol still operating on V2 ComposableStablePool contracts.