Balancer weighted pools: Custom weights, pricing and asset exposure

Balancer weighted pools use custom token weights to shape asset exposure and swap pricing within a liquidity pool. Weights describe target value proportions, while trading changes the token quantities held. Liquidity providers own shares of the whole basket. Balancer’s approved winddown schedules pausable pools for withdrawals only on October 30, 2026, with specific v3 extensions.

Unequal allocations connect asset exposure with the liquidity available for each swap. A smaller-weight reserve can create greater price impact even when total pool value looks substantial. That trade-off affects execution costs, changing holdings and the assets returned on withdrawal.

Bottom line: Under standard proportional withdrawal math, each token payout follows your ownership fraction, regardless of that token’s weight.

Read the exposure represented by pool shares

Reading a weighted position requires its registered tokens, configured weights, current balances and total share supply. Balancer Pool Tokens (BPT) represent ownership of that pool’s assets. For a standard v3 pool, dividing a holding’s BPT amount by total BPT supply gives its ownership fraction. Applying that fraction to each token balance identifies the underlying quantities represented by the position. A proportional-withdrawal query expresses the payout in token amounts, including any execution-specific adjustments.

Your BPT fraction measures basket ownership. An asset’s weight governs pricing and target value exposure, so the two percentages aren’t interchangeable.

Fixed weights and market-value exposure

A standard v3 Weighted Pool fixes its token weights at deployment. The creator chooses the allocation before launch; adding liquidity doesn’t rewrite those weights. Normalized weights sum to 100%, and each token must have at least a 1% weight. These are constraints of the standard v3 implementation.

An 80/20 allocation targets unequal shares of market value when pool prices align with external prices. It doesn’t require an 80/20 split in token units. Different token prices can produce very different quantities for the same value allocation. Arbitrage, meaning trades that exploit price differences between markets, adjusts balances toward the configured value proportions. Trading costs and limited activity can leave the pool away from that equilibrium.

How do custom weights affect a swap quote?

Custom weights change how a pair’s balances translate into the amount that a swap returns.

Weighted Math uses the invariant V = product(B_i ^ w_i), where B_i is a token balance and w_i is its normalized weight. An invariant is the balance relationship that the pricing calculation preserves for the fee-adjusted swap amount. The Balancer Vault supplies the v3 calculation with balances after decimal and applicable rate scaling.

With balances measured in token units, the fee-free spot price in input-token units per output-token unit is (B_in / w_in) / (B_out / w_out). This describes marginal pricing before a trade changes balances.

For an exact-input swap, the fee reduces the input that enters Weighted Math. A finite swap changes balances, so its average exchange rate differs from its starting marginal rate. Larger relative balance changes generally create greater price impact. The relevant liquidity is the selected pair’s balances, not the pool’s aggregate value alone. Execution also requires an initialized pool with swaps enabled.

Proportional and single-token liquidity changes

Proportional liquidity additions contribute the same fraction of each existing token balance. This preserves balance ratios and increases share supply. The required token quantities follow existing balances, even when the pool has unequal weights.

Single-token and other unbalanced additions change those ratios. Their mathematics includes a swap-like component, and the pool charges the applicable swap fee on the non-proportional amounts. BPT output therefore can’t be inferred by treating every contributed token as a balanced contribution. In v3, the pool’s configuration must permit the selected unbalanced operation.

A standard proportional withdrawal returns the same ownership fraction of every token balance without moving the pool’s relative prices. A single-token withdrawal concentrates the payout into one asset and applies different mathematics, including fees on the non-proportional component. Exact-BPT and exact-token withdrawal modes fix different sides of that calculation.

Normal v3 proportional withdrawals avoid the swap fee for unbalanced exits. However, adding liquidity and then withdrawing proportionally from that same pool within one Vault unlock call triggers a round-trip fee. Enabled hooks can also affect liquidity-operation outputs. These adjustments affect the payout estimate; the basic proportional formula doesn’t describe every configured execution.

Trading depth and the fee split

A smaller reserve can make a trade costly even when the pool holds substantial aggregate value. Price impact measures the curve movement caused by the trade; the swap fee is a separate deduction. In v3, configured protocol and pool-creator shares can take part of the collected fee, with the remainder accruing to liquidity providers through pool balances. Static settings or an enabled dynamic-fee hook determine the applicable swap fee. Network gas adds a separate transaction cost. A displayed fee percentage doesn’t establish the position’s net return.

Graphic: Balancer weighted pools - Trading depth and the fee split

Open full-size image

Does a larger token weight eliminate impermanent loss?

A larger token weight doesn’t eliminate impermanent loss. Impermanent loss compares the rebalanced liquidity position with holding its original token quantities at the same later prices. The comparison depends on relative price changes and the starting allocation. A position can gain market value while still lagging the value of its original holdings.

As one token appreciates relative to the others, arbitrage trades tend to remove some of that appreciating token from the pool. A higher weight retains more value exposure to that asset than an equal-weight allocation at equilibrium. It also leaves the position more exposed to that asset’s decline. Fees can offset some divergence loss, depending on actual trading activity and the fee share retained. Extreme asymmetry also reduces liquidity on the smaller-value side; there isn’t a weight setting that guarantees both favorable execution and superior returns.

Quote and complete a proportional withdrawal

For this hypothetical example, assume an active standard v3 weighted pool without hooks or rate adjustments. Its weights are 73.5% and 26.5%. Both tokens have 18 decimals. Balances are 12,345 first-token units and 6,789 second-token units, and total supply is 1,875 BPT. The holding to withdraw is 37.5 BPT. No liquidity addition occurs in the withdrawal’s Vault unlock session.

The holding represents 37.5 / 1,875 = 2% of the pool. Proportional arithmetic gives 246.9 first-token units and 135.78 second-token units. Each payout takes 2% of its own reserve; neither weight replaces that ownership fraction.

An offchain proportional-withdrawal query previews those outputs without permanently changing BPT holdings or pool balances. Its returned token amounts establish the expected payout. Set a minimum output for each token before execution. The withdrawal reverts if either output falls below its minimum. The withdrawal also requires the appropriate BPT authorization. Assume no balance or supply changes between the query and withdrawal.

The executed withdrawal burns 37.5 BPT and transfers the quoted token amounts to the recipient. Pool balances fall to 12,098.1 and 6,653.22 token units, and total supply becomes 1,837.5 BPT. The weights stay unchanged. Matching the BPT reduction and both received token amounts confirms this case’s payout; changed pool state requires a fresh estimate.

Withdrawal paths during the protocol winddown

The approved winddown restricts trading and new liquidity through pool or Vault pauses. Pausable pools are scheduled to move to withdrawals only on October 30, 2026. Pools that can’t be paused continue operating under the plan, with protocol fees set to zero where their contracts permit it. A zero protocol fee doesn’t necessarily remove the pool’s swap fee.

Specific v3 pools can receive partner-requested extensions through November 30, 2026, when the plan schedules the final v3 Vault pause. Extension requests must arrive by October 16, 2026. Bug bounty coverage ends on October 30, 2026, including for extended pools.

Where applicable, recovery mode keeps proportional withdrawals available during a pause. In v3, its recovery withdrawal uses raw token balances without calling the pool’s pricing math or hooks. It distributes the assets represented by those balances; it doesn’t convert the basket into a chosen token. Single-token liquidity mathematics therefore doesn’t describe this recovery payout.

Balancer weighted pools FAQs

What happens if a weighted swap exceeds its size limit?

Weighted Math rejects a swap that exceeds the applicable balance-ratio limit. In standard v3 math, the exact-input limit is 30% of the input balance supplied to the calculation, and the exact-output limit is 30% of its output balance. The exact-input test uses the fee-adjusted, scaled amount. These are per-operation mathematical limits, separate from the minimum-output or maximum-input limit that the trader sets.

Why can a hand calculation differ from a weighted-pool quote?

A hand calculation can differ because contract math uses fixed-point arithmetic and conservative rounding. Powers with fractional exponents introduce bounded approximation error, and exact-input output rounds downward. The contract can therefore return slightly less than ideal real-number arithmetic predicts. A complete quote also incorporates the applicable fees, scaled balances and any enabled hook behavior. Displayed balances may omit precision that the contract retains, so matching the formula alone doesn’t establish an identical token amount.

Are BPT from different weighted pools interchangeable?

BPT from different weighted pools represent different baskets and aren’t interchangeable units of ownership. Each pool has its own token balances, weights and share supply. Equal BPT quantities across two pools therefore don’t establish equal asset exposure or equal value. A transferable BPT token remains a claim on its particular pool, so its contract identity matters alongside the amount held.

Does ordinary Weighted Math require an external market-price oracle?

Ordinary Weighted Math derives swap prices from pool balances and weights without an external market-price oracle. Arbitrage trades transmit external price differences into changing reserves. Applicable token rates adjust accounting inputs. An attached hook can introduce further dependencies, so this property describes the basic formula rather than every customized execution.

Can standard v3 weighted-pool BPT provide their own rate to another pool?

Standard v3 weighted-pool BPT can’t provide a rate through their own getRate function, which reverts. An invariant-based BPT rate can have nonlinear rounding error that makes this use unsafe. This rules out using the weighted pool itself as the rate provider for WITH_RATE nesting. Nesting as a STANDARD token remains possible. An external rate provider is another option if it’s stable and has at most one unit of rounding error in its 18-decimal rate.

Which token order should a weighted-pool integration use?

A weighted-pool integration must align balances and normalized weights with the pool’s registered token order. Pairing one token’s balance with another token’s weight changes the calculation’s meaning, even when every number appears valid. Withdrawal amount arrays must identify the corresponding registered tokens too. The pool’s token list supplies that ordering; alphabetical ticker order or an interface’s display order doesn’t establish it.

Updated on