[Long English Thread] In-depth Analysis of the Balancer V2 Attack: Vulnerability Mechanism, Attack Steps, and Lessons Learned

Chainfeeds Guide:

The attacker deliberately set parameters, including the number of iterations and input amounts, to maximize the effect of precision loss.

Source:

Author:

BlockSec

Opinion:

BlockSec: On November 3, 2025, the Composable Stable Pool of Balancer V2, along with multiple on-chain projects based on its fork, suffered a cross-chain coordinated attack, resulting in total losses exceeding $125 million. BlockSec issued an early warning at the first moment and subsequently released a preliminary analysis. This was a highly sophisticated attack. Our investigation shows that the root cause stemmed from precision loss in invariant calculations, which was exploited to trigger price manipulation, thereby affecting the price of BPT (Balancer Pool Token). The attacker profited from specific stable pools by using a single batchSwap operation. The affected component was the Composable Stable Pool of Balancer V2. Such pools are designed for assets expected to maintain a near 1:1 exchange ratio, enabling large trades with minimal slippage and significantly improving capital efficiency for similar or correlated assets. Each pool has its own BPT, whose price can be approximately expressed as: BPT price = D / totalSupply, where D is the invariant in stable math, representing the pool's virtual total value. As can be seen from the formula, if D is mathematically reduced (even if no real funds are lost), the BPT price will appear lower. Balancer V2 provides the batchSwap() function, which allows multi-hop swaps within the Vault, with SwapRequest supporting both GIVEN_IN and GIVEN_OUT modes. In GIVEN_OUT mode, the caller specifies the desired output amount, and the pool calculates the required input amount. In Stable pools, when calculating the required input amount (amountIn), it is necessary to solve a polynomial equation based on the invariant formula, and these calculations are uniformly subject to Upscaling and Downscaling. In theory, these are opposite operations, but in practice, there is a difference in rounding direction: upscaling only uses rounding down (mulDown), while downscaling may use either rounding up or down (divUp/divDown). This inconsistency left room for exploitation. The root of the vulnerability lies in the use of rounding down when upscaling swapRequest.amount in BaseGeneralPool._swapGivenOut(). The value rounded down is used as amountOut for the input to _onSwapGivenOut(), causing the final calculated amountIn to be less than the actual required amount, thereby violating the usual design principle that rounding should favor the protocol. For pools like (wstETH/rETH/cbETH), the attacker could use fewer input assets to exchange for more of another asset, reducing the invariant D and thus depressing the BPT price. The attacker executed a two-stage attack. The first stage completed the core attack logic in a single transaction but did not immediately profit; the second stage extracted the profit through a separate transaction. The first stage was further divided into parameter calculation and batch swap steps. Taking the attack transaction on the Arbitrum chain as an example (TX: 0x7da32e…55773), the attacker first obtained pool parameters, including scaling factors, A (amplification coefficient), BPT exchange rate, swap fee, etc., then calculated trickAmt and simulated via a deployed auxiliary contract. The attacker precisely tuned the next swap parameters, including the number of iterations and the input/output values for each, by combining offline calculations and on-chain simulations. Each iteration executed a three-step swap: in the first step, the target token amount was pushed to trickAmt + 1; in the second step, the target token was swapped out again, triggering the rounding down in _upscale(); in the third step, a reverse swap was performed, truncating the pool balance down to "remove the highest two decimal places" before swapping back, e.g., 324,816 → 320,000. In some cases, since StableSwap math uses the Newton–Raphson method for solving, it could fail, so the attacker prepared two fallbacks, retrying with 9/10 of the original value. After the attack, due to some mechanisms being unable to be paused, Balancer's losses were amplified, and subsequent copycat attacks appeared on multiple chains, with total losses exceeding $125 million. This incident exposed four key issues in decentralized protocols: inconsistent rounding mechanisms, ever-evolving attacker techniques, inability to pause leading to expanded losses, and lack of real-time monitoring of initialization and operational states. Upscaling only allows rounding down, while downscaling allows both directions, and this asymmetry can accumulate into exploitable precision loss under extreme parameter construction. The rounding direction, which should always favor the protocol, in this case, ended up harming protocol interests. The attacker used a two-stage approach: the first stage executed the attack with no apparent profit, and the second stage withdrew funds separately, evading on-chain monitoring models. Every step of the attack combined off-chain and on-chain simulation, with the auxiliary contract even reusing Balancer's StableMath implementation, maintaining consistent error messages. After the attack, multiple chains followed suit, and many forked projects were also affected, indicating that as long as the stable math and rounding logic are consistent, the vulnerability can spread across ecosystems. The incident shows that DeFi protocols need higher-precision mathematical operations, stricter rounding verification and suspicious path simulation prevention mechanisms, as well as emergency pause capabilities in abnormal situations. [Original text in English]