A tiny rounding mistake inside Balancer’s V2 Composable Stable Pools (CSPs) turned into one of the most disruptive DeFi incidents of 2025. Attackers repeatedly exploited swap math to drain funds from affected pools across several networks. Public estimates for total losses reached roughly $128 million, though incident totals varied as investigators reconciled on-chain flows and recoveries.
Table Of Content
- What happened: the Balancer rounding error exploit (2025)
- Which networks were reported as impacted?
- Root cause: how a “small rounding error” becomes a huge drain
- Why EXACT_OUT paths can be fragile
- Attack mechanics: how funds were extracted
- How big were the losses?
- Where did the stolen funds go?
- Containment: how the ecosystem responded across chains
- Protocol-side actions (reported)
- Partner and chain actions (reported)
- Market impact: TVL shock and confidence damage
- What liquidity providers should do after an exploit like this
- Why rounding errors keep coming back in DeFi
- Lessons for DeFi teams: security is a product feature
- 1) Math invariants must be enforced, not assumed
- 2) Batch swaps demand extra paranoia
- 3) Cross-chain response plans should exist before the incident
- 4) Recovery tooling matters
- FAQ
- Was all of Balancer hacked?
- Is this “just a bug” or a design issue?
- What’s the biggest takeaway for everyday DeFi users?
- Final takeaway
This report explains what happened, why the vulnerability mattered, which systems were impacted, and what liquidity providers (LPs) and DeFi teams can learn from it. This is educational content, not financial advice.
What happened: the Balancer rounding error exploit (2025)
The exploit targeted Balancer V2 Composable Stable Pools—a specific pool type designed for stable-like swaps and composable liquidity. Reports say the attack began on November 3, 2025, and was detected by automated monitoring before Balancer confirmed an active exploit affecting CSPs across multiple chains.
Key point: This was not “Balancer as a whole” breaking. The incident was scoped to a particular pool implementation (CSPs) within V2. Other pool types, and Balancer’s newer designs, were broadly described as not impacted in early summaries.
Which networks were reported as impacted?
Early reporting described CSP exposure across a wide set of networks where those pools (or forks) were deployed, including Ethereum and several L2s / sidechains. The practical takeaway is that cross-chain deployments multiply incident complexity: funds can move fast, response coordination is harder, and containment tools differ per chain.
Root cause: how a “small rounding error” becomes a huge drain
Balancer’s V2 CSP design relies on scaling (“upscaling”) token balances so pools can handle assets with different decimals and pricing assumptions in a consistent internal unit. In stable-style swap math, that scaling layer is not cosmetic—it’s core logic.
In public reporting, the vulnerability centered on an upscale function used during batch swaps, where multiple swaps can be executed in a single transaction. The bug was associated with how rounding behaved in EXACT_OUT swaps (swap types where the output amount is fixed and the input adjusts). When rounding goes the wrong way under certain non-integer scaling conditions, attackers can push the pool math into states where the pool “pays out” more value than it should—then repeat it.
Why EXACT_OUT paths can be fragile
In stable pools, EXACT_OUT paths can be more sensitive because:
- They solve for the required input amount to achieve a fixed output.
- They can amplify rounding errors when decimals/scaling factors are non-integer or when math is re-applied in loops.
- They become dangerous if the function rounds in a direction that benefits the trader, rather than the pool.
That doesn’t mean EXACT_OUT is “bad.” It means the rounding and scaling rules must be obsessively consistent across every path.
Attack mechanics: how funds were extracted
Although each attacker strategy can differ in execution, reported reconstructions generally follow a similar pattern:
- An attacker identifies a CSP where scaling/rounding creates a profitable imbalance.
- They execute batch swaps that repeatedly trigger the faulty rounding behavior.
- The pool’s internal accounting drifts, letting the attacker extract value over multiple iterations.
- Stolen assets are then bridged and distributed to reduce traceability and increase exit options.
In many DeFi incidents, the “one big transaction” narrative is wrong. The reality is often repeatability—a bug that can be exploited again and again until liquidity is exhausted or the system is paused.
How big were the losses?
Public estimates varied during the response window. Several reports cited totals around $128M, while other summaries and follow-ups referenced different numbers as teams verified affected pools and tracked returned funds. This is common: early numbers can reflect peak observed outflows, while later numbers may reflect confirmed net losses after recoveries.
One reason incident accounting is messy is that “loss” can mean different things:
- Gross drained assets (what left pools)
- Net loss (after recoveries/returns/frozen balances)
- Impacted TVL (capital leaving the protocol due to fear, not just theft)
Where did the stolen funds go?
Initial coverage described rapid post-exploit movement: assets were bridged across chains and, in some reporting, partially routed through privacy tools to complicate tracking. This “bridge + spread” playbook is common after high-profile DeFi incidents because it forces responders into a race across multiple ecosystems.
Containment: how the ecosystem responded across chains
Balancer and partners reportedly moved quickly to contain the breach. In multi-chain incidents, “containment” is rarely one action—it’s a bundle of steps across protocol controls, partner coordination, and chain-specific interventions.
Protocol-side actions (reported)
Public summaries of Balancer’s mitigation steps included:
- Disabling new CSP creation by turning off the relevant factory (to prevent expansion of the attack surface).
- Halting incentives tied to affected pools (to prevent emissions from drawing fresh liquidity into danger).
- Enabling recovery-mode withdrawals for paused pools where possible, allowing LPs to withdraw underlying assets proportionally.
The goal of these steps is not just to stop the attacker. It’s also to reduce secondary damage—like new LPs depositing into compromised pools or incentives continuing to flow into a broken environment.
Partner and chain actions (reported)
Several reports described a broader response involving whitehats, security teams, and ecosystem partners. In some accounts, recoveries and freezes were achieved through a combination of:
- Whitehat interventions to front-run attacker extraction and route funds toward recovery.
- Issuer/bridge actions to freeze or halt specific assets when legally/technically possible.
- Chain-specific emergency measures in environments where governance or validators can intervene.
These measures are controversial in DeFi culture, but they represent the reality of modern on-chain finance: many ecosystems now prioritize user protection and recovery when a clear exploit is underway.
Market impact: TVL shock and confidence damage
Beyond the direct theft, the exploit triggered a confidence shock. Reporting referenced a sharp drop in Balancer’s TVL in the days around the incident, reflecting both the drained funds and additional withdrawals from users reducing risk exposure.
That second component matters: in DeFi, a security incident often causes “voluntary TVL loss” on top of “forced loss.” The protocol can be technically fixed, but trust takes longer to rebuild.
What liquidity providers should do after an exploit like this
If you were providing liquidity during a CSP-specific incident (or you’re evaluating a similar pool in another protocol), here’s a practical, safer checklist:
- Identify your exact pool type (CSP vs. other stable pools vs. weighted pools). Do not assume “V2” means all pools share the same risk.
- Check whether the pool is paused and whether recovery mode withdrawals are enabled.
- Verify incentive status: if gauges/emissions were halted, don’t chase yield that no longer exists.
- Review exposure across chains: a pool on one chain might be safer than a similar-looking pool on another due to different deployments/forks.
- Reduce complexity under uncertainty: during active investigations, simpler positions are easier to control and unwind.
Internal companion: If you want to build a more defensive routine for self-custody and approvals, use our guide:
Ultimate Crypto Security Guide: Self-Custody.
Why rounding errors keep coming back in DeFi
“Rounding error” sounds harmless—like a spreadsheet annoyance. In smart contracts, it can be catastrophic because rounding is not noise; it’s an economic rule. If the rule consistently favors traders over pools (even by a tiny unit), bots can industrialize it.
Common reasons rounding bugs recur:
- Decimals complexity across tokens and wrappers (wstETH-style assets, rebasing tokens, synthetic vault tokens).
- Multiple swap paths (EXACT_IN vs EXACT_OUT) implemented with slightly different rounding assumptions.
- Batch operations that magnify tiny errors through repetition.
- Cross-chain forks that copy code but change environments, assets, or assumptions.
Lessons for DeFi teams: security is a product feature
This incident reinforces a set of hard truths for DeFi builders and auditors:
1) Math invariants must be enforced, not assumed
Stable pool math needs explicit invariants that prevent “free value” extraction under any rounding direction. In practice, that means tests that simulate adversarial rounding and repeated swaps under edge-case scaling.
2) Batch swaps demand extra paranoia
Batching is powerful UX—but it also increases composability of exploits. Anything that makes repeated operations cheaper can make repeated exploitation cheaper too.
3) Cross-chain response plans should exist before the incident
If a protocol runs on many networks, it needs pre-agreed coordination channels with major partners, bridges, and monitoring teams—because minutes matter.
4) Recovery tooling matters
“Recovery mode” style withdrawals can reduce chaos by giving LPs a clear exit path when pools are paused. It doesn’t remove loss, but it can prevent additional harm.
Internal companion: For readers learning how exploits happen and how attackers bypass security habits, see:
Heist: How New Scams Bypass Crypto Wallet Security.
FAQ
Was all of Balancer hacked?
No. Reporting described the exploit as scoped to V2 Composable Stable Pools (and some forks). Other pool types and newer deployments were described as not affected in early incident coverage.
Is this “just a bug” or a design issue?
In DeFi, it’s both. The direct cause is a bug, but the underlying risk is a design reality: stable pool systems are mathematically dense, and tiny edge cases can become money printers if rounding rules are inconsistent.
What’s the biggest takeaway for everyday DeFi users?
Don’t evaluate risk by token ticker or protocol brand alone. Evaluate the specific pool type, the chain, and whether the protocol has containment + recovery tooling when something goes wrong.
Final takeaway
The Balancer CSP rounding exploit is a reminder that the next era of DeFi won’t be defined only by yield or speed—it will be defined by market structure, formalized security, and incident readiness. Tiny math decisions shape giant economic outcomes.
Disclosure: This article is for informational purposes only and does not constitute financial advice.









