Balancer Attack Analysis

Balancer Attack Analysis

Yesterday, on July 3, 2025, Balancer was hacked for over $100 million due to a precision-loss bug.
While the official post-mortem hasn't been released yet, most pools are already paused or drained.
This post is my own analysis of the exploit.

In this blog, I will:

  • identify the root cause,
  • analyze the copycats,
  • and discuss how to profit legally (not by hacking!).

Attack Analysis

Initially, several security researchers claimed the exploit was merely an access-control bug similar to the Abracadabra attack (e.g., DeFimon, MyWebacy).

However, the transactions they posted were just the withdrawals, not the actual exploit. For example:

Balancer's advanced internal balance feature (which is actually not vulnerable) allows users to perform internal accounting instead of ERC-20 transfers.
For instance, when swapping ETH → DAI → USDC, the DAI transfer may never appear on-chain because the balance is updated internally.
Users can also deposit or withdraw their internal balances anytime. The hacker’s withdrawal transaction was simply such a withdrawal.

First question, why does the hacker split the attack into 2 steps (attack-then-withdraw)? Despite technical problems, one particular reason might be that this can partially mitigate front-running as the attack transaction is “not profitable” to some of the front runners unless they taken balancers' internal balance into consideration. However, he was still front-run by several bots as discussed later.

The vulnerability lies in precision loss within Balancer's Composable Stable Pool implementation — a modified version of Curve’s StableSwap AMM.

These pools contain multiple pegged assets (e.g., wstETH, ETH), and the LP token (BPT) can itself be swapped within the pool.
Swapping BPT → token1 effectively withdraws liquidity and swaps another token internally.

Balancer introduced a scaling factor to support related (not 1:1) assets.
For example, if 1 wstETH = 1.05 ETH, then:

  • scaling factor of wstETH = 1.05
  • scaling factor of ETH = 1.0

These are stored as integers in 1e18 precision (e.g., 1.05 × 1e18 = 105e16).

The scaled amount is calculated as:

scaled_amount = (raw_amount * scaling_factor) / 1e18

Here comes the problem: If raw_amount is very small (e.g., 8 wei), integer division causes precision loss of up to 12.5% (1/8).

Another contributing factor is the internal balance mechanism — users can flash-mint tokens during a batchSwap, use them within the same transaction, and only need to settle balances by the end. This made the exploit even more powerful.

Now, let's check into the attack transaction itself. We can take 0xe9245fb124c3a6ff6a0e39c6d0db02b74b3a3d805f6bf016f4b9ac56cbfb73ae on base as an example. On a high level, the attack was split into 4 phases (1 calculation + 3 actions).

1. Calculation

The attacker uses a standalone contract to simulate the swap states to trigger the exactly precision loss. This contracts' code is copied from the Balancers' own contracts because it also contains some custom errors in Balancers' code.

2. Manipulation

The attacker uses "flash-minted" LP token to manipulate the pool state by swapping BPT → token1 and BPT → token2 repeatedly, making the pools' raw balances very small (in the order of 10_000~100_000). As the flash-minted BPT cannot be withdrawn, the attacker needs to swap them to token1 and token2. After manipulation, as shown in the figure below, the raw balances of token1 and token2 are very small (40,000). This is the first parameter (we can call it b).

3. Precision-Loss Loop

The attacker repeatedly swapped between the two tokens to amplify the precision loss. They optimized a variable $small$ satisfying:

maximize{ (small * scaling_factor) % 1e18 }

This will create the maximum precision loss when swapping $small$ amount of token1 to token2 or vice versa. Specifically, one iteration contains 3 swaps:

  1. token1 → token2: swap (b - small - 1) tokens to create the precision condition
  2. token1 → token2: swap (small) tokens to trigger precision loss
  3. token2 → token1: swap ~90% back to restore balance

alt text

Each loop caused a small but compounding imbalance — roughly proportional to 1 / small — steadily draining LPs. The attacker repeated this until the profit margin was large enough.

repay

The attacker finally swaps the remaining token1 and token2 back to BPT to repay the flash-minted LP tokens. This process also needs to be gentle to avoid large price impact. This is part of the withdrawing process as loss is already realized.

After that, they withdrew all tokens from internal balances — the withdrawal many researchers initially misidentified as the attack itself.

A Speed Run Copycat Game

While the main hacker only exploited some of the largest pools on Balancer, there were still food left on the table, extracted by whitehats, copycat attackers, and some MEV bots. These include:

  • some small pools not gained by the main attacker;
  • the “dead body” of the bigger pools;
  • Balancer forks.

Front-running

While the attack implementation is complicated, the attacker has put his calculation contract on-chain. On the one hand, this avoids mismatch of state between off-chain calculation and on-chain execution; on the other hand, this also allows others to copy the attack easily. As a result, there are several front-runners who front-run the main attacker to gain some profit.

Interestingly, the attacker, while creating this masterpiece hack, does not appear to be experienced. Evidences:

  • The attacker could have used flashbots or directly submit to builders to avoid front-running, but he did not.
  • The attacker left some debugging code (foundry logs) in the execution contract which could have been deleted.
  • The hacker took quite a long time (around 20 minutes) to finish all the attacks across ethereum, optimism, arbitrum, polygon, etc.

Back-running - Copycats

One noting thing is that the attack is too complicated to implement because all the steps need to be precisely calculated to trigger the precision loss. Despite this, the very first copycat (by the way, he seems to be a notorious copycat, who also copied the squid bridge attack recently) started exploiting within one hour after the main attack (07:46 UTC -> 08:39 UTC)

How could this be possible? After checking the log of the copycat's transaction, you can find all the logging info from the attacker's contract, meaning the copycat just copied the attacker's contract code and deployed it by himself! So just by replacing the pool address and sender address, the copycat can launch the same attack, with super low effort.

In the following several hours, a large number of copycats appeared, exploiting various pools on Balancer. However, no exceptionally, all the copycats used the same code base as the original attacker, just changing the pool address and sender address.

Fork Fallout

Next the disaster comes to Balancer forks. As Balancer is open source, several forks have been created in the past years, including Beets, BEX, PHUX, etc. According to DeFiLlama's data, there are 27 Balancer V2 forks. (however, only V2 stable pools are vulnerable)

The largest fork, BEX, was also affected and exploited for around $13 million. BEX is the largest DEX on Berachain and has a large number of stable pools. As a result, berachain paused their chain to avoid attackers bridging assets out. Other forks, such as Beets on Sonic & Optimism, also suffered from the same precision loss attack.

It was a dark day for DeFi, a single precision loss bug replicated across multiple chains and protocols. Even ETH’s price dropped shortly after, possibly related.

Pausing

You might ask, why didn't Balancer just pause the pools after they are aware of the vulnerability? The reason is that they did pause some of the pools, however, Balancer tries to be "decentralized" so that the pool's parameters and pausing state can only be changed within a window of deployment. This means if the pool is deployed for a long time, it cannot be paused anymore. Unfortunately, some of the vulnerable pools have already passed the pausing window, so Balancer cannot pause them anymore.

How to profit (not hacking!)

After I see on Twitter that Balancer was hacked, I was trying to figure out where I can short $BAL token. Unluckily, the only CEX/DEX is Mexc where there is no much liquidity. While I was searching, I realized I could short $BERA because BEX is the largest Balancer fork and it was also affected by the same vulnerability.

Another opportunity is to trade on this Polymarket market: Another crypto hack over $100m in 2025?. It remained a low price within 10 minutes after the attack happened, as reported by Defimon.

Other analysis I find useful