Balancer is an AMM built around one shared Vault
Bottom line: Decentralized exchange and AMM protocol for token swaps and liquidity pools, with a shared Vault that routes trades across pools.
Balancer is a decentralized automated market maker that separates token accounting from pool logic through a shared Vault. It routes swaps, liquidity deposits, and withdrawals through smart-contract pools whose math defines prices for assets such as ETH, stablecoins, liquid staking tokens, and other ERC-20 tokens. Its distinctive feature is flexibility: pools can use different weights, fee settings, and custom logic while relying on the same core accounting layer.
The Vault, routers, and pools in one trade
The strongest design choice in Balancer is the Vault, a smart contract that holds pool tokens and records credits and debts during a transaction. Routers sit in front of it as the user-facing path for swaps and liquidity actions. Pools contribute the price math, while the Vault handles settlement, token scaling, and the final check that every owed amount has been paid.
A swap starts when a wallet or smart contract calls a router. The router unlocks the Vault, the pool calculates the output or input amount, and the Vault records the result. Settlement happens at the end of the same transaction. If the credits and debts do not balance, the transaction reverts, so the accounting model stays strict even when several pool operations are combined.
Weighted pools turn portfolios into market makers
Balancer is known for weighted pools because they let liquidity providers set token ratios beyond the familiar 50/50 split. An 80/20 pool, for example, gives one token a larger portfolio weight while still making a market between both assets. This design appeals to projects and treasuries that want liquidity without holding equal dollar exposure to every token in the pool.
Weighted math adjusts prices as traders move pool balances away from the target weights. When demand pushes one asset out of balance, the price changes until arbitrage trading restores the intended relationship. Liquidity providers receive BPT receipts that represent their share of the pool, and those receipts rise or fall with the pool's asset values, fee revenue, and liquidity movements.
Stable and yield-bearing pools handle tighter assets
Stable pools serve assets that are designed to trade close together, such as stablecoin pairs or different forms of a staked asset. Their math creates deeper liquidity near the expected price relationship, which reduces slippage for trades where the assets track a similar value. That makes them useful for routing between USDC-like assets, wrapped yield tokens, or liquid staking positions.
The v3 architecture also supports rate providers and token scaling, which matters when an asset's exchange rate changes over time. A yield-bearing token does not always behave like a flat ERC-20 balance, so the protocol needs a way to account for the rate used by the pool. This is one reason the shared Vault model matters: it keeps token handling consistent while pools focus on their market logic.
Where swap fees enter the trade
On Balancer, a swap fee is charged on the amount entering a trade. Fees also apply to non-proportional add or remove liquidity actions, because those actions have the same economic effect as trading against the pool. A proportional deposit keeps the pool in balance; an unbalanced deposit changes the ratio of assets and pays for that imbalance.
Standard weighted pools use pool-level fee bounds, and stable pools use their own bounds. The v3 design also supports dynamic fees through hooks, so a pool can compute a fee at execution time rather than relying only on a fixed setting. Dynamic fees suit specialized pools that react to volatility, swap direction, peg pressure, or custom strategy rules.
BAL after the 2026 governance revamp
BAL is the governance token for Balancer, and its role changed materially in Q2 2026. The protocol halted BAL emissions, discontinued veBAL, moved protocol fees to the DAO Treasury, and shifted Snapshot voting to raw BAL across production chains. That means the older gauge-driven incentive model is historical context rather than the current operating model.
The token still anchors governance over major protocol decisions such as new pool factories, new deployments, supply decisions, and minting parameters. Day-to-day operations sit with designated governance and treasury structures, while larger changes move through token-holder voting. This split gives the protocol a cleaner decision path without relying on ongoing liquidity mining inflation.
Adding liquidity and reading BPT balances
When someone supplies assets to a Balancer pool, they receive BPT as a receipt for their share. A proportional deposit adds every required token in the pool's current ratio. An unbalanced deposit supplies more of one asset than the pool expects and pays swap fees on the portion that changes the pool's balance. Removing liquidity works in the reverse direction through proportional or single-token exits.
Before adding funds, a user should read the pool composition, fee setting, total liquidity, recent volume, and token types. A pool with correlated assets behaves very differently from a volatile multi-token basket. Fee revenue helps offset trading movement, but it does not erase price divergence between assets or the risk of a token losing its expected relationship.
Using the app with a wallet
A new user starts by connecting a self-custody wallet on a supported EVM network, selecting the input and output tokens, reviewing the quoted route, and submitting the transaction with enough native gas token for that chain. The app or router selects available pools and returns a price, expected output, price impact, and transaction cost before the wallet signs anything.
For liquidity, the workflow is similar but includes pool selection and deposit type. The useful checks are practical: token addresses, pool weights, fee percentage, network, wallet balance, and gas cost. Approval transactions are separate from the actual swap or deposit when a token has not been approved before, so the first use of a new asset often requires two wallet confirmations.
Risks that matter before a swap or deposit
More broadly, Balancer pools use audited contracts and strict Vault accounting, yet DeFi risk remains real because smart contracts, token contracts, or external rate sources can fail. Stable pools carry depeg risk, weighted pools carry price divergence risk, and all pools carry gas and slippage risk during fast market moves. The most important transaction-level check is the minimum amount received before signing.
Liquidity providers also face pool-specific exposure. A concentrated or custom pool behaves according to its own math, not a generic AMM template. Hooks add flexibility, but they also make the behavior of a specialized pool more important to understand. The safest reading habit is concrete: identify every token, read the fee model, and know what the pool is designed to hold.
Uniswap, Curve, and CoW Swap as nearby choices
Uniswap is the most recognizable constant-product and concentrated-liquidity DEX for direct ERC-20 trading. Curve is specialized around stable assets and correlated liquidity. CoW Swap focuses on intent-style execution and batch auctions that protect users from some forms of miner or validator extractable value. This protocol is closest to a programmable liquidity layer, because its Vault and pool framework support many market designs under one architecture.
The right venue depends on the trade. A simple ETH to USDC swap belongs wherever the route gives the best execution after gas and price impact. A treasury pool, weighted token basket, liquid staking market, or custom AMM design fits better where pool math and Vault settlement are designed for variation from the start.
What to know about Balancer
Does Balancer support swaps without holding BAL?
Yes. A trader does not need BAL to swap tokens through the protocol. They need the input token, enough native gas token for the selected network, and any required token approval before the swap executes. BAL matters for governance voting and protocol-level decisions, not as a mandatory trading token for every user transaction.
Can a pool include more than two tokens?
Yes. Weighted pools support multi-token designs, so a pool can act more like an on-chain index or treasury basket than a two-asset pair. Each token receives a target weight, and the pool math prices trades against those weights. More tokens add complexity because the provider's exposure spans every asset in the pool.
Do I need ETH for gas on every supported network?
No. The gas token depends on the network used for the transaction. Ethereum mainnet uses ETH, while other EVM networks use their own native gas asset. A wallet must hold enough of that native token to pay for approvals, swaps, deposits, and withdrawals. Without gas, the wallet cannot submit the transaction.
What happens if one token in a stable pool depegs?
A depeg changes the risk profile of the entire pool. Stable pool math assumes the assets remain closely related, so a broken peg lets traders remove the stronger asset and leave more of the weaker asset behind. Liquidity providers then hold a pool share with greater exposure to the impaired token until the market relationship recovers or they exit.
Route quotes failing before a swap: what does that mean?
A failed quote means the route cannot produce a valid transaction under the selected settings. Common causes include too little liquidity, an unsupported token, excessive price impact, stale wallet state, a paused pool, or a network mismatch. Changing the trade size, checking the network, refreshing balances, or selecting a more liquid route usually identifies the issue.
Is BAL still emitted to liquidity providers?
No. The 2026 governance revamp halted ongoing BAL emissions and retired the previous incentive schedule. Liquidity providers now evaluate pools mainly through swap fees, token exposure, pool design, and any separate incentives that a project or pool creator funds. Older references to gauge voting and emissions describe the prior model.