Balancer limits are 30% Weighted Pool swap boundaries
Balancer limits are smart-contract bounds in Balancer Weighted Pools: an exact-in swap sends no more than 30% of the input token balance into WeightedMath, while an exact-out swap requests no more than 30% of the output token balance. In Balancer V3, the Vault deducts the swap fee before the exact-in amount reaches the formula. A larger request reverts, so order sizing must use the pool's live scaled balances and the chosen swap kind.
Updated
They are weighted Pool smart-contract bounds that cap swap inputs and outputs at 30% of their respective token balances, so larger trades revert.
Large-swap reverts at the pool boundary
When a Weighted Pool receives an amount above its branch-specific ratio, Balancer limits terminate the swap inside WeightedMath before the Vault can settle either ERC-20 transfer.
The exact-in check
An exact-in order fixes what leaves the trader's wallet. In Balancer V3, the Vault converts that raw ERC-20 amount into an 18-decimal scaled amount, calculates the swap fee, and subtracts the fee before calling the pool. WeightedMath then requires the post-fee amount to be no greater than 30% of the scaled input-token balance. A larger math amount throws MaxInRatio. Balancer V2 expresses the corresponding failure as BAL#304. Gas spent on a reverted transaction remains a chain cost, while no swap settlement occurs.
The exact-out check
An exact-out order fixes the amount leaving the pool. WeightedMath compares that requested scaled output with 30% of the output-token balance before calculating the required input. A request above the ceiling throws MaxOutRatio; Balancer V2 labels the corresponding condition BAL#305. Balancer V3 adds the swap fee to the calculated input afterward. The user's maximum-input setting controls payment, while the pool-side ratio controls whether the requested output enters the formula. Choose the swap kind before calculating the applicable boundary.
Size the order from live Vault balances
When the selected pool and swap kind are known, the correct ceiling comes from that pool's live scaled balance, not from wallet inventory or total token liquidity elsewhere.
Read the balance snapshot
Balancer V3 passes balancesScaled18 into the pool's onSwap function. The Vault first normalizes ERC-20 decimals and applies registered token rates, producing values with 18-decimal fixed-point precision. For exact-in, multiply the input token's relevant live balance by 30%. For exact-out, apply 30% to the output token's live balance. The denominator belongs to one pool on one chain. That snapshot isolates the pool's own available inventory. Liquidity in another Weighted Pool, a Stable Pool, Ethereum, Arbitrum, or Polygon does not enlarge it. A fresh quote supplies the usable snapshot, including the route and swap kind.
Leave room for execution
The code rejects only values above the rounded 30% product, so equality passes that specific comparison. A quote still reflects one block-state snapshot. Another swap or liquidity change alters the balance before execution, and fixed-point scaling rounds toward the protocol. Submitting at the mathematical edge therefore creates a brittle order. Reduce the requested amount or use a route that distributes it across pools. This sizing margin is separate from the minimum output on exact-in and the maximum input on exact-out. A related walkthrough covers Balancer review.
Slippage tolerance protects the quoted exchange outcome; it does not raise either 30% contract ratio.
Fixed parameters around the 30% boundary
When a standard Balancer V3 Weighted Pool is the venue, several fixed parameters frame the 30% ratio and separate contract bounds from live market conditions.
Importantly, Balancer V2 and Balancer V3 WeightedMath both set maximum input and output ratios of 30%. The Solidity constant appears as 0.3e18 in V2 and 30e16 in V3, two equivalent 18-decimal representations.
| Parameter | Fixed value | Custody or control |
|---|---|---|
| Exact-in math amount | At most 30% of the scaled input balance | WeightedMath enforces; the Vault accounts for pool tokens |
| Exact-out requested amount | At most 30% of the scaled output balance | WeightedMath enforces; the Vault accounts for pool tokens |
| Normalized token weight | At least 1%; all weights total 100% | The factory validates the pool configuration |
| Combined effect | Deterministic pool boundaries | The user authorizes settlement through a router |
Standard V3 Weighted Pools register 2 to 8 tokens. Each normalized weight is at least 1%, and the set must total exactly 100%; a two-token pool therefore reaches a widest feasible split of 99/1. The standard V3 Weighted Pool swap-fee range runs from 0.001% to 10%. Fees use 18-decimal fixed-point values, 24 bits of Vault storage, and 0.00001% resolution. Separate unbalanced-liquidity calculations constrain invariant ratios between 70% and 300%. These ranges remain fixed at the contract layer. Those figures govern pool construction and liquidity operations, while the trade's next decision still comes from its live balance.
Splitting a trade across valid pool hops
When one Weighted Pool cannot accept the requested size, a router must divide the flow into smaller valid hops or choose other liquidity before execution.
Sequential slices in one pool
Two smaller swaps are not equivalent to one oversized swap. Each settled slice changes both token balances, so the next slice receives a new 30% denominator and a new price. The input balance rises, the output balance falls, and price impact accumulates along the weighted curve. Executing several transactions also pays network gas several times. A contract route that touches the same pool repeatedly still faces the check on every pool call, using the state available at that step.
Alternate paths and pools
Broadly, Balancer's Smart Order Router and BatchRouter distribute a route across registered pools when suitable liquidity exists. A broader route may also use Uniswap V3 or Curve, but every Balancer Weighted Pool hop retains its own ratio check. Routing remains chain-local: Ethereum liquidity does not combine with Arbitrum or Polygon balances inside one swap. Compare the combined output, gas, and user-set limits against a smaller single-pool order. The decisive question is whether added route depth offsets extra execution complexity.
Exact-in and exact-out apply different ceilings
When the trader fixes the input, WeightedMath checks the net formula amount; when the trader fixes the output, it checks that request against the corresponding live pool balance.
The two 30% constants are branch-specific, not simultaneous caps on both sides of every swap. Exact-in invokes MaxInRatio after the V3 Vault removes the fee from the scaled input. Its calculated output follows the weighted formula and the pool's minimum-balance checks. Exact-out invokes MaxOutRatio on the desired output, then calculates the input and adds the fee. A wallet's slippage field adds another condition: minimum received for exact-in, or maximum paid for exact-out. Select the branch that matches which quantity must remain fixed.
Pool weights govern price impact, not the ratio
When two pools hold the same balances but assign different normalized weights, their price curves diverge even though Balancer limits retain the same 30% boundary for each branch.
A 50/50 Weighted Pool values each side symmetrically in the invariant. An 80/20 pool gives the two assets unequal normalized weights, changing the spot-price relationship and the output produced by the same input. The 30% check does not inspect whether the quote is attractive. It only keeps the power-function inputs inside defined numerical bounds.
Weighting matters most before the ceiling. As trade size grows relative to reserves, the balance ratio moves along the curve and marginal execution worsens. A successful transaction near 30% may therefore carry substantial price impact even though it satisfies MaxInRatio or MaxOutRatio. Compare the quoted output with alternate pools before deciding how much capacity to use.
Why does a quote succeed but execution revert?
When a Balancer quote and the mined transaction observe different pool state, the later call can cross MaxInRatio, MaxOutRatio, or the user's slippage limit during final Vault settlement.
A quote is a state snapshot, not a reservation of pool capacity.
An intervening swap, add, remove, token-rate update, or dynamic-fee calculation changes at least one input to execution. The route may also select a different pool when software refreshes the quote. An Ethereum RPC simulation only evaluates the state used for that call; it does not reserve balances for the submitted transaction. If the live denominator shrinks, an order previously below 30% moves above it. If the ratio remains valid, a minimum-output or maximum-input condition may still reject the changed price.
Refresh the route, inspect the swap kind, and lower or redistribute the amount before resubmitting. The new quote determines the next viable execution choice.
WeightedMath and Vault enforcement under the hood
When an EVM call reaches a standard Weighted Pool, the Vault scales balances, applies fees and rounding, and then WeightedMath enforces the applicable ratio in Solidity.
Absent anything unusual, Balancer V3 source uses Solidity 0.8.24-compatible contracts and 18-decimal fixed-point arithmetic. For exact-in, WeightedMath computes the rounded product of the input balance and 30e16, then reverts only when the supplied math amount is greater. Exact-out performs the parallel comparison against the output balance. The library rounds the calculated output down and the required input up, favoring pool accounting at precision boundaries. MaxInRatio and MaxOutRatio identify the failing branch without converting a market quote into a protocol promise.
The Vault remains the accounting layer for registered token balances, while Router and BatchRouter calls carry user limits into settlement. ERC-20 token amounts are scaled before pool math and converted back to raw units afterward. Balancer V2 follows the same 30% WeightedMath concept with its numbered errors; Balancer V3 uses custom Solidity errors. This sequence explains both the hard ceiling and the correct response: resize or reroute the order using fresh pool state.
Before you start with Balancer limits
Does the Balancer swap fee count toward the 30% exact-in cap?
Yes, Balancer V3 fee sequencing affects the exact-in amount that WeightedMath tests. The Vault scales the user's raw ERC-20 input, calculates the swap fee, and subtracts it before passing the remainder to the pool. WeightedMath compares that post-fee value with 30% of the live scaled input balance. Exact-out works differently: the requested output faces its 30% check first, and the fee is added to the calculated input afterward.
Can BatchRouter bypass MaxInRatio or MaxOutRatio?
No, BatchRouter cannot bypass a Weighted Pool's math bounds. Each Weighted Pool hop calls its own onSwap logic, and WeightedMath checks the applicable live balance for that hop. BatchRouter may split flow among several pools or connect multiple assets in one route, which reduces the amount assigned to one pool. Every assigned amount must still independently satisfy that pool's ratio, scaling, minimum-balance, and user-limit checks.
Which liquidity operations use limits other than the 30% swap ratio?
Proportional liquidity additions and removals do not enter the same WeightedMath swap branch. Standard Balancer V3 Weighted Pools apply separate invariant-ratio bounds to unbalanced liquidity operations: the defined range runs from 70% to 300%. Those checks concern changes to the pool invariant, not a trader's exact-in or exact-out swap amount. A router must therefore classify the operation before interpreting a revert or estimating usable capacity.
Are Balancer Stable Pools governed by the WeightedMath 30% limits?
No, Stable Pools use StableMath rather than WeightedMath, so the Weighted Pool rule should not be transferred to them by name alone. StableMath uses an amplification parameter and separate balance, invariant, and convergence constraints. A route that crosses both pool types evaluates each hop under that hop's own contract math. The pool type, swap kind, live balances, and specific router path identify the relevant limit.
Do token decimals change the 30% Balancer limit?
No, token decimals do not change the percentage itself. Balancer V3 converts raw ERC-20 units into 18-decimal scaled values before the pool performs WeightedMath calculations, then converts settlement amounts back to raw units. Scaling and rate adjustments affect the rounded boundary by the smallest representable units, especially at the edge. They do not turn 30% into a different percentage, so integrations should quote scaled pool state instead of comparing raw token units directly.
