The Balancer Exploit: How Olympix Would Have Prevented the $121M Loss

On November 3, 2025, at 7:46 AM UTC, the Balancer V2 protocol suffered one of the most sophisticated exploits in DeFi history. A subtle rounding inconsistency in Composable Stable Pools enabled attackers to drain approximately $121.1M across Ethereum, Arbitrum, Base, Optimism, and Polygon.

This wasn't a brute force attack. It was precision engineering, exploiting the mathematical underbelly of DeFi through carefully calibrated micro-swaps that eroded pool invariants without triggering alarms. Thanks to rapid response from security partners, whitehat rescuers, and emergency interventions, approximately $45.7M was protected or recovered. The losses could have been prevented with proactive security measures that detect precision vulnerabilities before deployment.

The Attack: Death by a Thousand Wei

The exploit weaponized a two-stage attack pattern. First, manipulate the pool state. Second, withdraw clean. All executed via batchSwap for atomicity, bypassing single-swap guards.

Preparation Phase: Finding the Rounding Cliff

The attacker didn't just attack blindly. They gathered comprehensive pool state data: token scaling factors, amplification parameters, fees, BPT rates, and current balances. Then they deployed a simulation contract and repeatedly called a helper function 0x524c9e20, passing arrays of balances, scaling factors, token indices, desired output amounts, amplification, and fees.

Using large iteration counts (approximately 100 billion iterations across 25 refinement loops), the attacker identified specific swap amounts that would land tokens on wei-level rounding cliffs. These are the precise edges where rounding errors compound.

Atomic Execution: The Invisible Drain

Once calibrated, the attacker executed the sequence on-chain through atomic batchSwap transactions:

1. Position Setup: Swap BPT for underlying tokens to position one token (e.g., cbETH) at a rounding edge (balance = 9 wei)
2. Precision Exploit: Execute a crafted EXACT_OUT swap (e.g., swap amount = 8) that, due to upscale/downscale rounding asymmetry, produced a smaller computed input than expected, silently reducing the pool invariant D
3. Value Extraction: Swap underlyings back into BPT at this deflated virtual price, pocketing excess BPT value
4. Compound: Repeat these swaps inside a single atomic transaction, allowing the invariant to erode over many iterations without triggering sanity checks

The attacker repeated this technique across multiple pools and chains: Arbitrum, Polygon, Base, Sonic, and Optimism, compounding the drain wherever pauses or protections were absent.

After accumulating underpriced BPT in their internal balance, the attacker later redeemed through managerUserBalance to EOA 0xaa760d53541d8390074c61defeaba314675b8e3f.

The Root Cause: Asymmetric Rounding

At the heart of the exploit was a rounding direction mismatch in Composable Stable Pools' scaling logic. The protocol used mulDown for upscaling but divUp/divDown for downscaling. This asymmetry meant the EXACT_OUT path (_swapGivenOut) could understate the required amountIn.

In the _swapGivenOut function, the amountOut was adjusted for token decimals and rate, then rounded down by _upscale before being passed into the calculation. While outputs are typically rounded down, StableMath's mechanics caused the amountIn to also be rounded down, producing an amountIn that was too low and allowing the caller to underpay for the given amountOut.

Repeating carefully tuned micro-swaps inside a single batchSwap() compounded tiny wei-level truncations, quietly reducing the invariant D and thus the BPT price (≈ D / totalSupply) without triggering reverts or sanity checks.

The exploit required three preconditions: the underlying rounding error in exact out swaps, rate providers to introduce imprecision in the math, and a low liquidity state required to magnify the imprecision enough to be exploitable. Only Composable Stable Pools satisfied all three conditions, and only if they actually incorporated BPT and rate providers.

The Response: Security Architecture in Action

Despite the severity, the response demonstrated the value of layered security:

07:46 UTC — First malicious transactions detected simultaneously across five chains

07:46 UTC — Bitfinding successfully front-ran the attacker on Ethereum Mainnet, recovering approximately $964k

07:52 UTC — Hypernative's monitoring systems flagged suspicious activity and established emergency communication

08:07 UTC — V6 Composable Stable Pool implementations paused across affected networks, protecting $19.3M in liquidity

08:14 UTC — SEAL 911 proactively contacted Balancer, having independently flagged attacker wallets

09:50 UTC — First public disclosure made via official channels

11:01 UTC — Recovery Mode activated on affected pools, enabling users to safely withdraw remaining funds

Recovery Summary

Through coordinated response efforts, approximately $45.7M in user funds were protected or recovered:

• V6 Pool Pauses: Protected $19.3M in vulnerable liquidity
• Whitehat Recoveries: $4.6M recovered across multiple chains under the SEAL Safe Harbor Framework
• StakeWise DAO Emergency Operation: $21.8M in osETH and osGNO recovered (90 minutes after initial exploit)
• Other Interventions: Gnosis implemented zero daily bridge limits, freezing cross-chain movement of stolen funds

What Olympix Found: Biased Rounding in Rate-Augmented Scaling

Following the exploit, Olympix ran a comprehensive analysis of the Balancer Composable Stable Pool contracts using BugPoCer, our automated vulnerability detection system. The results identified the exact vulnerability pattern that enabled the $121M exploit.

High Severity: Biased Rounding in Upscale with Rate-Augmented Scaling Factor

Unit Name: BaseGeneralPool / BasePool

Locations: ScalingHelpers.sol: _upscale(), BaseGeneralPool.sol: _swapGivenIn()

Description: The pool normalizes token amounts via _upscale(amount, scalingFactor), which uses FixedPoint.mulDown and therefore always rounds down. This is normally safe when the scaling factor represents only decimal normalization (10^(18−decimals)), because the truncation is economically negligible.

However, in this implementation, _scalingFactors() is overridden to include non-unitary, potentially dynamic token rates. Embedding token exchange rates inside the scaling factor amplifies rounding effects and creates a systematically biased truncation during _upscale().

The calculation works as follows:

_upscale(amount, scalingFactor) = floor(amount * scalingFactor / 1e18)

When scalingFactor includes a non-integer rate (e.g., a yield-accruing or rebasable token), small amount values or low-liquidity balance conditions can cause the floor operation to produce material percentage differences, not just ≤1 wei dust.

Exploitation Mechanism: This becomes exploitable when combined with multi-step swap paths (GIVEN_IN + GIVEN_OUT), repeated scaling and descaling, and the attacker's ability to position the pool into extremely skewed balance configurations.

The attacker leveraged exactly this vulnerability by:

1. Using rate providers to amplify the rounding effects beyond negligible levels
2. Positioning pools in low-liquidity states where the percentage impact of rounding became material
3. Executing repeated micro-swaps that compounded the biased rounding across multiple operations
4. Exploiting the asymmetry between upscaling (always rounds down) and the expected pool behavior

This is the precise mechanism that enabled the invariant degradation attack. The systematic downward bias in _upscale() when combined with rate-augmented scaling factors created the rounding cliff that the attacker exploited.

How This Could Have Been Prevented

The Olympix finding demonstrates that automated precision analysis could have identified the vulnerability pattern before deployment.

Pre-Deployment Detection

BugPoCer's precision analysis specifically flagged the biased rounding in rate-augmented scaling factors. This type of vulnerability is extremely difficult to catch in traditional audits because:

• It only becomes exploitable under specific conditions (rate providers + low liquidity + repeated operations)
• The individual rounding errors appear negligible in isolation
• The vulnerability exists in the interaction between multiple contract components
• Testing requires adversarial calibration to find exploitable balance states

Automated analysis can systematically detect these patterns by analyzing:

• Rounding direction consistency across scaling operations
• The amplification effects of dynamic rates embedded in scaling factors
• Cumulative precision loss across multi-step operations
• Exploitability conditions under various pool states

Targeted Remediation

With this finding, developers could have:

1. Separated decimal normalization from rate application: Keep scaling factors as pure decimal adjustments and apply rates separately with appropriate rounding
2. Implemented compensating rounding bias: Ensure that when rates are involved, rounding favors the pool, not the caller
3. Added invariant guards: Validate that the pool invariant D cannot decrease through normal swap operations
4. Restricted low-liquidity operations: Implement minimum liquidity thresholds or additional safety checks when pools approach exploitable states

The Fix That Would Have Worked

The core issue was embedding dynamic, non-unitary rates inside the scaling factor while maintaining a consistent downward rounding bias. The fix would have been straightforward:

// Instead of: _upscale(amount, scalingFactor_with_rate)

// Which always rounds down via mulDown

‍

// Use: Apply rate separately with compensating bias

scaled = _upscaleDecimals(amount, decimalScalingFactor); // normalize decimals

rateAdjusted = _applyRate(scaled, rate, ROUND_UP); // apply rate, round up to favor pool

This separates concerns and ensures that rate application doesn't inherit the downward bias appropriate only for decimal normalization.

Why Traditional Audits Missed This

This exploit reveals the limits of traditional security approaches.

Audits Are Snapshots: The vulnerable code had been audited by multiple top-tier firms. But audits are point-in-time reviews. As new attack vectors emerge and complexity increases, code that was "secure enough" can become exploitable.

Rounding Appears Safe in Isolation: In manual review, seeing mulDown for upscaling appears correct. Downward rounding is typically the safe direction for calculating amounts owed by users. The vulnerability only emerges when you understand that rate-augmented scaling factors change this assumption.

Requires Cross-Component Analysis: The vulnerability required understanding how _upscale(), _scalingFactors(), rate providers, and swap paths interact across multiple transactions. Manual reviewers would need to trace through:

• How scaling factors are computed
• How rates are embedded
• How repeated operations compound errors
• What pool states make this exploitable

This level of cross-component, stateful analysis is precisely what automated tools excel at.

Testing Can't Catch Everything: Even comprehensive test suites struggle with precision bugs because they require adversarial calibration. The attacker performed exactly this kind of simulation with 100 billion iterations to find the rounding cliff. Standard test suites don't include this level of adversarial edge-case exploration.

The Broader Lesson: DeFi Math Breaks at Its Weakest Decimal

The Balancer exploit proves that security in DeFi now means defending against economic engineering, not just coding bugs. A single wei-level rounding inconsistency cascaded into a $121M loss because:

1. Rate providers amplify precision vulnerabilities: What's safe for decimal normalization becomes exploitable when combined with dynamic exchange rates
2. Batch swaps and composability enable compound exploitation: Atomic execution prevents individual sanity checks from catching cumulative errors
3. Low-liquidity states magnify percentage impacts: Rounding errors that are negligible at normal liquidity become material at pool edges
4. Forks inherit every upstream weakness: Beets and Beethoven X suffered copycat attacks before mitigations could propagate

What V3 Got Right

Balancer V3 was completely unaffected by this attack. While V3 was designed before this specific vulnerability was discovered, its architectural principles proved effective:

• Consistent 18-decimal precision: Calculations use uniform precision with upscaling and downscaling handled by the Vault rather than individual pools
• Explicit rounding controls: Every arithmetic operation has an enforced rounding direction, preventing subtle biases from emerging through component interaction
• Separated rate application: Rates are not embedded within scaling factors, eliminating the amplification effect
• Formal verification: Development employed rigorous formal verification, including properties for roundtrip swap invariance and BPT share value invariants

The incident validates the value of building protocols with security-first architectural principles, even when specific attack vectors aren't yet known.

Looking Forward: The Case for Proactive Security

The Balancer exploit demonstrates a harsh reality: you can't audit your way to safety in DeFi. The industry needs to move from reactive security (audit and pray) to proactive security (continuous verification).

What Protocols Need Now

Protocols need to:

1. Enforce biased rounding: Ensure all rounding operations favor the protocol, never the attacker. Be especially careful when embedding dynamic values in scaling operations
2. Strengthen invariant checks: Implement guards that catch cumulative precision loss before it becomes exploitable
3. Test adversarial edges: Don't just test happy paths. Simulate attackers searching for rounding cliffs at pool edges and unusual states
4. Continuous analysis: Security must be ongoing, with automated tools running on every code change

What Olympix Provides

Our approach combines:

• Automated precision analysis: Systematic detection of biased rounding and scaling inconsistencies
• Rate amplification detection: Identifying when dynamic values amplify supposedly negligible precision loss
• Multi-step operation analysis: Tracking how rounding errors compound across transaction sequences
• Exploitability validation: Determining which precision bugs are actually exploitable under adversarial conditions
• Continuous monitoring: Not just pre-deployment audits, but ongoing security as code evolves

Conclusion

The Balancer V2 exploit shows how far DeFi security has to go. A tiny rounding bias, the kind that appears safe in isolation and passes multiple audits, cascaded into a $121M loss when combined with rate providers and low-liquidity conditions.

Olympix's post-incident analysis identified the exact vulnerability: biased rounding in rate-augmented scaling factors that enabled systematic precision loss exploitation. This finding demonstrates that automated security analysis can detect the subtle, multi-component vulnerability patterns that lead to real-world exploits.

Traditional audits focus on obvious bugs and known attack patterns. But the next major exploit won't look like the last one. It will be a novel combination of seemingly safe operations that interact in unexpected ways. Automated analysis can find these patterns by systematically exploring how components interact under adversarial conditions.

Mathematical vulnerabilities exist in production code right now. The only question is whether protocols will find them before attackers do.

Don't let mathematical vulnerabilities drain your TVL. Olympix's automated security analysis catches precision bugs, biased rounding, and rate amplification vulnerabilities before deployment.

[Request a Security Analysis]

Attacker Addresses for Reference:

• 0x506d1f9efe24f0d47853adca907eb8d89ae03207
• 0xaa760d53541d8390074c61defeaba314675b8e3f
• 0xf19FD5c683a958ce9210948858B80d433F6BfaE2

Relevant Transaction Hashes:

• Ethereum: 0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742
• Arbitrum: 0xe4dfc8b8b54eb7e101d59cd9f87f389186b2e8f6e188557ae9dfdbea2b12e703
• Polygon: 0x167993d4cc39771923a6cd11d2d6e73a1b68c7464ea3c76ba41fbd32df7a96da

Related guides

• Balancer hack lessons