Balancer limits are the eight-token boundary for Weighted Pools

Balancer limits are the fixed composition rules for a standard Balancer V3 Weighted Pool: it registers two to eight tokens, assigns every token at least 1% weight and requires all normalized weights to total 100%. The ninth asset cannot be appended to that pool. It needs another pool and a multi-pool route, or a different architecture. These limits belong to the pool and Vault contracts, so interface choices do not expand them.

Updated on

Decide whether the basket belongs in one pool

A basket belongs in one Weighted Pool only when it has two to eight compatible tokens and a fixed weight for each.

Start with the asset list, not the desired pool name. Count distinct ERC-20 contract addresses, confirm each token's decimals and decide whether every position deserves at least a 1% normalized weight. Then ask whether one invariant should price every pair in the basket. A ninth asset changes that answer: the composition must be divided across separate pools, and the Balancer BatchRouter must connect those pools when a viable route exists. Each pool keeps its own balances, weights, fees and Balancer Pool Token supply, so the split also divides liquidity.

That decision fixes the architecture before deployment, when changing course requires creating a new pool rather than editing the existing asset array.

Pair coverage grows faster than slot count. Five assets create 10 unordered pairs inside one invariant, while eight create 28. That density is useful only when shared balances support those routes. If two subgroups rarely trade against each other, separate pools may concentrate liquidity more deliberately, even before the ninth-token ceiling forces a split.

Weighted Pools, Managed Pools and routed baskets

Standard Balancer V3 Weighted Pools keep fixed weights and eight slots, while V2 Managed Pools followed a different contract model.

The distinction matters whenever older material uses the word "Balancer" without naming the pool family. A standard V2 Weighted Pool also supported up to eight tokens. The separate V2 Managed Pool constructor accepted between two and 50 tokens, allowed gradual weight changes and exposed token addition or removal functions. Balancer V3 takes another route: its Vault registration layer accepts only two through eight tokens for a pool, including custom pools registered there. A routed basket can span several pools, yet it has several invariants and several BPT positions rather than one unified basket.

How many tokens fit in one Weighted Pool?

One Balancer V3 Weighted Pool holds at least two and at most eight registered pool tokens. The Balancer V3 Vault rejects registrations below two tokens or above eight tokens.

The count uses unique token contract addresses in the pool's registration array. WETH, WBTC, USDC, DAI and BAL would therefore consume five slots, regardless of their displayed ticker lengths or target weights. The Vault enforces ascending contract-address order, refuses a repeated address and excludes both the zero address and the pool's own address. BPT sits outside this underlying-asset count: WeightedPool issues it to represent liquidity ownership, while the registered ERC-20 tokens supply the balances used by WeightedMath. At eight underlying assets, every storage position reserved for standard weights is occupied.

Weight arithmetic under the eight-token cap

Weight arithmetic narrows the design before liquidity enters, because every normalized weight is fixed at deployment and must satisfy hard bounds.

Weights use 18-decimal fixed-point values inside the contract, but percentages make the constraint easier to read. Each token must carry at least 1% and all normalized weights must sum exactly to 100%. A two-token pool therefore permits a largest weight of 99%, since the second token needs 1%. Three tokens reduce that ceiling to 98%. With eight tokens, seven minimum allocations consume 7%, leaving at most 93% for one dominant asset. An eight-way equal split of 12.5% each also satisfies both checks.

Market movement changes balance values and spot prices, but it does not rewrite the normalized weights stored by a standard V3 Weighted Pool.

Token registration and decimal constraints

Pool registration succeeds only when every token has valid metadata, a unique sorted address and a supported Balancer V3 token configuration.

The Vault reads decimals through IERC20Metadata and rejects a token reporting more than 18 decimals. It scales raw balances to 18-decimal fixed-point values for pool math, so six-decimal USDC and eighteen-decimal WETH can share one Weighted Pool. Token descriptors use either the STANDARD or WITH_RATE type. A STANDARD token has no rate provider and does not request yield-fee accounting; a WITH_RATE token requires a rate provider. WeightedPoolFactory passes this ordered configuration to the Vault, where an unsorted pair, a duplicate contract or inconsistent rate settings stop registration before initialization.

Swap size and invariant boundaries

Pool composition fits only if expected operations also remain inside WeightedMath's swap and unbalanced-liquidity limits.

The neighboring topic is handled in Using Balancer. WeightedMath caps an exact-input swap at 30% of the input token balance and an exact-output swap at 30% of the output token balance. The percentage applies after Balancer converts amounts to its scaled accounting units. A larger user order needs splitting or routing, and market price impact still depends on the live balances and the two token weights. The 30% checks protect the numerical range of the weighted power calculation; they are contract boundaries rather than forecasts of an acceptable trade.

Unbalanced liquidity operations carry separate invariant-ratio bounds: the new invariant cannot fall below 70% or rise above 300% of the prior value in one operation. A V3 Weighted Pool also exposes a 0.001% minimum and 10% maximum swap-fee percentage. Fees use 18-decimal fixed-point inputs and are stored in the Vault with 0.00001% resolution. Those figures bound configuration, while the selected pool fee, route balances and chain gas determine a transaction's actual cost.

Can a ninth token be added later?

A ninth token cannot be added later because a standard Balancer V3 Weighted Pool permanently fixes its registered composition at deployment. The pool has no function for extending its registered token set. The Vault would reject a nine-token registration even for a custom V3 pool, because the eight-token ceiling lives in shared Vault storage and registration logic.

To include another ERC-20 asset, deploy a separate pool with its own BPT and connect liquidity through Balancer routing. Existing liquidity does not migrate automatically; the new pool starts with its own balances, fee setting and ownership distribution. Routing changes the accounting boundary. One BPT position does not claim liquidity in the second pool, because each pool mints its own BPT and sets its own fee. A route uses one swap's output as another swap's input, subject to both pools' curves, 30% ratio checks and available balances.

A concrete pre-deployment checklist

A deployment-ready composition passes five checks before anyone selects initial balances or approves ERC-20 transfers.

  • Count between two and eight unique underlying token addresses.
  • Assign every weight at least 1% and make the total exactly 100%.
  • Confirm every token reports 18 decimals or fewer through IERC20Metadata.
  • Sort token addresses, then align weights and token configurations to that order.
  • Keep planned swaps within 30% balance ratios and unbalanced operations within 70% to 300% invariant ratios.
  • Set the pool fee between the 0.001% minimum and 10% maximum.

The portfolios the eight-token design serves

The eight-token format suits compact on-chain baskets whose assets need one weighted invariant and immutable target weights.

Two-token pairs preserve the broadest weight range, from 1% and 99% through 50% and 50%. Larger baskets trade that range for shared liquidity across more pair combinations. Well-known Ethereum ERC-20 assets such as WETH, WBTC, USDC, DAI and BAL illustrate how five distinct contracts still leave three open slots; the tickers do not establish compatibility, weight quality or liquidity depth. Once the intended set reaches nine assets, Balancer limits move the design to multiple pools, where routing joins separate invariants rather than expanding one Weighted Pool.

This format rewards deliberate composition rather than maximum asset count. A smaller set leaves more room for asymmetric weights and concentrates balances among fewer pair paths. An eight-asset set offers 28 pair combinations, but every additional token takes at least 1% of normalized weight. The last slot is worthwhile when its shared invariant earns a clear role in the basket.

Useful questions about Balancer limits

How many decimals does BPT use when the pool tokens differ?

Balancer Pool Token uses 18 decimals regardless of whether the underlying assets use six, eight or eighteen decimals. BPT represents a claim on one pool's liquidity and its supply is tracked separately from the registered asset array. The Vault scales underlying balances for pool math, while BPT keeps its fixed metadata precision. An eight-token Weighted Pool therefore issues an 18-decimal BPT without converting the native decimal format of USDC, WBTC, WETH or any other underlying token.

Could a Balancer hook raise the eight-token ceiling?

A Balancer hook cannot raise the Vault's eight-token registration ceiling. Hooks participate at configured swap or liquidity points after a pool follows the Vault's registration rules. The token-count check runs in shared Vault logic, so WeightedPoolFactory output and custom V3 pools face the same two-to-eight boundary. Supporting nine assets requires multiple registered pools or protocol-level code outside that constraint.

What determines deployment gas for an eight-token Weighted Pool?

Deployment gas reflects contract creation, token registration and per-token configuration, so eight tokens require more work than two. The payable amount still changes with the chain's gas price, factory implementation and transaction calldata, which prevents a durable currency figure. Rate providers, hooks and role-account settings add further execution. Estimate gas against the exact deployment transaction on the intended network; token count supplies direction, not a fixed ETH amount. Initialization consumes additional gas when liquidity is first supplied.

Why must token addresses be sorted before pool creation?

Token addresses are sorted so every parallel array uses one deterministic registration order. Normalized weights, token types, rate providers and later balance indexes must refer to the same asset positions. WeightedPoolFactory expects callers to align these values before the Vault stores them. An out-of-order address or duplicate address stops registration, preventing an ambiguous mapping between one token and another token's configuration.

How should initial balances reflect the fixed pool weights?

Initial balances should express the opening prices intended by the fixed weights, because WeightedMath derives pair prices from both balances and normalized weights. A 50%/50% pool does not require equal token units when the tokens have different values. Every registered asset needs enough balance for initialization, and the contract then computes BPT from the invariant. Poorly chosen balance ratios start the pool at an unintended price even though the weights sum correctly. Later trades move balances along the same curve.

Does the eight-token limit also cap the number of route hops?

The eight-token limit applies inside each pool, not to a universal number of swap hops. Balancer's BatchRouter accepts paths containing separate pool steps, and each step uses the tokens registered in its selected pool. Transaction gas, available liquidity and route construction still constrain a usable path. Crossing several pools links their outputs and inputs for one settlement, but it never combines their token arrays into one expanded Weighted Pool.