Technical Analysis: How was Balancer Hacked for $120 Million, and Where was the Vulnerability? On [date], Balancer, a popular decentralized exchange (DEX), was hacked for $120 million in a sophisticated attack. The vulnerability exploited in this atta...

Original Article Title: "Balancer $120M Hack Vulnerability Technical Analysis"
Original Source: ExVul Security

Foreword

On November 3, 2025, the Balancer protocol was attacked on multiple chains including Arbitrum and Ethereum, resulting in a $120 million asset loss. The attack was primarily due to a dual vulnerability involving precision loss and Invariant manipulation.

Chainlink's infrastructure has long maintained the highest standards in the Web3 space, making it a natural choice for X Layer, which is dedicated to providing institutional-grade tools for developers.

The key issue in this attack lies in the protocol's logic for handling small transactions. When users conduct exchanges with small amounts, the protocol invokes the _upscaleArray function, which uses mulDown for rounding down values. When the balance in the transaction and the input amount both hit a specific rounding boundary (e.g., the 8-9 wei range), a noticeable relative precision error occurs.

This precision error is propagated to the calculation of the protocol's Invariant value D, causing an abnormal reduction in the D value. The fluctuation of the D value directly lowers the price of the Balancer Pool Token (BPT) in the Balancer protocol. The hacker exploited this suppressed BPT price through a premeditated trading path to conduct arbitrage, ultimately leading to a massive asset loss.

Exploited Transaction:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Asset Transfer Transaction:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Technical Analysis

Attack Vector

The entry point of the attack was the Balancer: Vault contract, with the corresponding entry function being the batchSwap function, which internally calls onSwap for token exchanges.

From the perspective of function parameters and restrictions, several pieces of information can be obtained:

1. The attacker needs to call this function through the Vault and cannot call it directly.

2. The function will internally call _scalingFactors() to get the scaling factor for scaling operations.

3. The scaling operation is concentrated in either _swapGivenIn or _swapGivenOut.

Attack Pattern Analysis

BPT Price Calculation Mechanism

In Balancer's stable pool model, the BPT Price is a crucial reference point that determines how much BPT a user receives and how much each BPT receives in assets.

In the pool's exchange calculation:

Where the part acting as the BPT Price anchor is an immutable value D, which means controlling the BPT Price requires controlling D. Let's analyze the calculation process of D further:

In the above code, the calculation process of D depends on the scaled balances array. This means that an operation is needed to change the precision of these balances, leading to an incorrect D calculation.

Root Cause of Precision Loss

Scaling Operation:

As shown above, when passing through _upscaleArray, if the balance is very small (e.g., 8-9 wei), the rounding down in mulDown will result in significant precision loss.

Attack Process Detailed

Phase 1: Adjustment to Rounding Boundary

Phase 2: Trigger Precision Loss (Core Vulnerability)

Phase 3: Exploiting Depressed BPT Price for Profit

Above, the attacker uses Batch Swap to perform multiple exchanges in one transaction:

1. First Exchange: BPT → cbETH (balance adjustment)

2. Second Exchange: wstETH (8) → cbETH (trigger precision loss)

3. Third Exchange: Underlying Asset → BPT (profit-taking)

All these exchanges occur in the same batch swap transaction, sharing the same balance state, but each exchange calls _upscaleArray to modify the balances array.

Lack of Callback Mechanism

The main process is initiated by the Vault. How does this lead to accumulating precision loss? The answer lies in the passing mechanism of the balances array.

Looking at the above code, although Vault creates a new currentBalances array each time onSwap is called, in Batch Swap:

1. After the first swap, the balance is updated (but due to precision loss, the updated value may be inaccurate)

2. The second swap continues the calculation based on the result of the first swap

3. Precision loss accumulates, eventually causing the invariant value D to significantly decrease

Key Issue:

Summary

The Balancer attack can be summarized for the following reasons:

1. Scaling Function Uses Round Down: _upscaleArray uses mulDown for scaling, which results in significant relative precision loss when the balance is very small (e.g., 8-9 wei).

2. Invariant Value Calculation Is Sensitivity to Precision: The calculation of the invariant value D relies on the scaled balances array, and precision loss directly affects the calculation of D, causing D to decrease.

3. Lack of Invariant Value Change Validation: During the swap process, there was no validation to ensure that the change in the invariant value D was within a reasonable range, allowing attackers to repeatedly exploit precision loss to suppress the BPT price.

4. Accumulation of Precision Loss in Batch Swaps: Within the same batch swap, the precision loss from multiple swaps accumulates and eventually leads to significant financial losses.

These two issues—precision loss and lack of validation—combined with the attacker's careful design of boundary conditions, resulted in this loss.

This article is a contribution and does not represent the views of BlockBeats.