Balancer is a Practical Lens on Weighted Pools, BAL Voting, and Fees

Bottom line: Automated market maker protocol for token swaps and liquidity pools, with weighted pools supporting custom token weights in a single pool.

Balancer is a programmable AMM where weighted pools, Vault routing, and BAL governance shape the way token swaps and liquidity positions behave in one trading venue. Its signature feature is the ability to create pools with custom token weights, so a pool does not have to hold assets in a fixed 50/50 split. That design gives traders swap depth and gives liquidity providers more control over exposure.

The weighted-pool idea that changes AMM exposure

A standard constant-product pool keeps two assets in equal value. Weighted pools take a broader approach: a pool defines weights such as 80/20, 60/20/20, or another supported mix, and its math prices trades around those target proportions. On Balancer, that means a liquidity provider in an 80/20 WETH/BAL-style pool holds more of the primary asset while still supplying usable swap liquidity for both sides.

This matters because the weight changes the economic profile. A higher weight gives that token more representation in the pool and lowers its relative rebalancing pressure when its price rises. The tradeoff appears in execution quality: the lower-weight token has less depth, so large swaps through that side meet more slippage. The pool is therefore closer to an automated portfolio with exchange functionality than a plain two-token market.

How swaps move through the Vault

The protocol architecture centers on a Vault that handles token accounting while pool contracts define pricing rules. Balancer v3 formalizes more of the shared machinery in the Vault, leaving pool types to focus on math, hooks, fees, and permissions. A swap route enters through a router, reads the relevant pool state, and settles token movement through the Vault rather than each pool independently holding every behavior pattern.

That separation matters for builders and liquidity managers. Weighted pools, stable pools, boosted pools, and Gyroscope-style pools share a settlement layer while preserving different pricing logic. Hooks add another extension point, including dynamic fee behavior or custom pool reactions around swaps and liquidity events. The shared architecture reduces repeated contract logic and makes specialized AMM design easier to reason about.

Where 80/20 pools fit a portfolio

The best-known weighted format is the 80/20 pool. It gives one token dominant exposure and pairs it with a second asset for market-making. Many governance-token liquidity designs use this pattern because it creates a liquid market without forcing holders to split their position evenly between the governance token and ETH, WETH, or another pairing asset.

An 80/20 position still rebalances as prices move. If the dominant token rallies, the pool sells some of it into the other token to maintain the target weight. If it falls, the pool accumulates more of it. That is the AMM job. The important point is that the weight sets the intensity of that rebalancing. Compared with a 50/50 pool, the position keeps more directional exposure to the heavier token.

Fees at the pool, protocol, and yield layers

On Balancer, swap fees are charged on the token amount entering a trade, and unbalanced liquidity additions or removals also pay fees on the non-proportional portion. Standard weighted pools in v3 define their own fee bounds, with the documented range running from 0.001% to 10%. Stable pools use a different lower bound because their math and use case differ.

Fee configuration has several layers. A pool starts with a static swap fee, and authorized accounts or governance-controlled permissions set or update it. Dynamic swap fees use hooks, so a pool reads a fee from custom logic at execution time. Yield fees apply to supported yield-bearing tokens when the token rate increases and the pool is configured for that treatment.

• Swap fees compensate liquidity providers and may feed protocol-level accounting.
• Unbalanced joins and exits pay fees on the part that changes pool proportions.
• Dynamic fees let a pool respond to volatility, peg pressure, or trade direction.
• Yield fees apply to token-rate growth rather than ordinary spot-price movement.
• Pool creator fees exist when a pool is registered with that recipient model.

Current BAL voting after the veBAL era

The current Balancer governance model uses BAL voting power across production chains where the token is deployed. The older veBAL-based Snapshot strategies have been retired, so the vote-counting model now centers on raw BAL plus recognized BAL exposure from the 80/20 BAL/WETH pool token on Ethereum. This shift matters for anyone reading older tokenomics material because veBAL no longer supplies an extra voting multiplier.

Balancer still recognizes legacy locked positions for their underlying BAL exposure when calculating Ethereum voting power. The relevant view contract counts raw BAL, directly held 80/20 BAL/WETH pool tokens, and the face value of pool tokens locked inside veBAL, then converts the pool token amount into its BAL share. Delegation remains part of the Snapshot workflow, and voting power is summed across supported chains.

Adding liquidity without treating every pool alike

A new Balancer liquidity position starts with pool selection, not with a generic deposit button. The pool type, token weights, swap fee, total liquidity, trading volume, token quality, and external incentives all change the risk profile. A weighted pool with volatile assets behaves differently from a stable pool built for correlated tokens such as stablecoins or liquid staking pairs.

Before joining, a user chooses whether to add tokens proportionally or unbalanced. A proportional add follows the pool's current weights and avoids pushing the pool away from its target composition. An unbalanced add resembles a built-in swap plus a liquidity deposit, so the fee treatment and price impact deserve attention. The received Balancer Pool Token represents the claim on the pool, including the changing mix of underlying assets.

Risks that come from weights, hooks, and token design

More broadly, Balancer pools inherit the usual AMM risks and add a few mechanics worth understanding. Weight choice affects impermanent loss, slippage, and how strongly a position rebalances. Token design affects transfer behavior, rate reporting, and integration reliability. Hooks introduce custom code paths, so the behavior of a pool goes beyond the base weighted formula when hooks are enabled.

Smart contract risk also differs by pool age and factory. Newer v3 contracts use the current architecture, while older pools may still operate from previous deployments. Liquidity providers should read the exact pool composition before depositing because a pool token represents every asset inside the pool, not only the asset that attracted them to the position. Thin liquidity magnifies price impact on exits.

Uniswap, Curve, and Gyroscope as nearby choices

Day to day, Balancer differs from Uniswap by emphasizing custom pool weights and multi-token pools rather than a dominant concentrated-liquidity model. Curve is strongest around correlated assets and stable-swap style depth. Gyroscope designs focus on specialized pool math for resilient liquidity. These alternatives overlap in swaps and liquidity provision, yet each leads with a different market structure.

The right venue depends on the job. A simple volatile-token swap may route through Uniswap liquidity. A stablecoin trade may favor Curve-style depth. A custom treasury mix, governance-token liquidity program, or multi-asset AMM design points back toward the weighted-pool model. That is the distinct angle: it turns AMM liquidity into a configurable allocation engine with fees, routing, and governance wrapped around it.