Balancer is a Decentralized Exchange and Automated Market Maker for Programmable Liquidity

Balancer v3 centers LP entry on the Router and BPT receipt

More broadly, Balancer v3 makes the Router, the Vault, and the resulting BPT balance the three checkpoints that define a completed liquidity entry. The current retail path moves approved ERC-20 assets through a Router, settles them in the Vault, and mints BPT to record the position. The interface confirmation matters, yet the decisive evidence is the BPT ownership recorded for the intended recipient. That receipt is also the asset later presented for an exit.

Set the network, wallet, and gas asset first

The pool’s network decides which wallet balances, approval targets, and native gas asset you’ll need before any deposit can settle.

On Ethereum, choose chain ID 1 and hold ETH for gas. Arbitrum uses 42161 with ETH; Base uses 8453 with ETH; Gnosis uses 100 with xDAI; Optimism uses 10 with ETH; Polygon uses 137 with POL; and Avalanche C-Chain uses 43114 with AVAX. These are separate ledgers. A USDC balance on one doesn’t satisfy a deposit on another, even when the token symbol looks identical. The pool contract and BPT also exist at chain-specific addresses. MetaMask, Rabby, or a WalletConnect session should show the same chain before the interface builds the approval.

Check the complete input set shown for the pool and keep every required token in the connected address. An EVM address is 20 bytes, rendered as 40 hexadecimal characters after the 0x prefix, so compare the complete contract when two assets share a ticker. Keep a gas balance separate from the deposit, such as ETH for USDC on Base, chain ID 8453.

Do I approve every token before adding liquidity?

Each input token needs enough allowance for the chosen Balancer Router path unless a permit signature supplies that authorization in the same call.

Standard ERC-20 approvals

An ERC-20 allowance is a 256-bit amount assigned by the token contract to a specific spender. Approving 100 USDC doesn’t authorize 100 WETH, and approval on Ethereum doesn’t carry to Base. Balancer v3 retail routes pull deposit tokens through Permit2, so the wallet first grants the relevant token-to-Permit2 allowance. An allowance set to 0 closes the amount; a limited allowance should cover the displayed maximum input, not merely the quoted input.

Each token owns its own allowance slot. A two-token pool with neither allowance available therefore needs two approval transactions before the add call.

Permit and Permit2 authorization

Permit2 stores allowance amounts as 160-bit values, while expiration and nonce fields are each 48 bits. Balancer’s Router accepts EIP-712 Permit2 data, allowing the operation permission and liquidity call to travel together after the token-to-Permit2 allowance exists. The BPT contract also implements ERC-2612, so a Router allowance for a later exit can be signed as permit data. A conventional v, r, s ECDSA signature occupies 65 bytes, and its deadline remains part of the signed message.

With the required allowances available, one deposit transaction carries the Permit2 data and add call. Without them, a two-token deposit takes three on-chain transactions: two approvals and one liquidity addition.

Seven Router paths define the position boundaries

Seven Balancer Router paths cover the position lifecycle, and every path uses an exact value plus a maximum or minimum boundary.

The comparison separates what the caller fixes from what the contract calculates. Exact-input paths consume the stated token or BPT amount and protect the other side with a minimum. Exact-output paths deliver the stated BPT or token amount and protect the spend with a maximum. Proportional actions preserve the pool’s asset ratio, while single-token actions select one asset. Custom calls defer interpretation to the pool, but their maximum inputs and minimum outputs remain hard boundaries. These seven paths describe contract capabilities; the interface shows only those enabled for that pool at that moment.

If execution crosses the signed minimum or maximum, the call reverts and no position change settles. For a single-token exact-output exit, the decisive figure is maxBptAmountIn.

What confirms that the LP position exists?

A Balancer LP position exists when the add transaction succeeds and the intended recipient owns the minted BPT or its wrapped equivalent.

Wallet state

Balancer Pool Token uses 18 decimal places and implements ERC-20 and ERC-2612 permit behavior. Read the BPT contract’s balanceOf value for the recipient, then compare the change with the quote. For standard pools, the pool contract is also the BPT contract. A direct unstaked join increases wallet BPT. Wrapped Balancer Pool Token represents BPT at a fixed 1:1 rate; if the flow stakes the receipt, the holding contract changes, so the wallet’s bare BPT balance can remain 0.

Transaction record

A transaction hash is 32 bytes, shown as 64 hexadecimal digits or 66 characters with the 0x prefix. The receipt should report success on the correct chain, and the BPT token’s ERC-20 logs should show the mint to the intended recipient. Compare the pool contract, recipient, input transfers, and BPT amount as one record. A token symbol alone isn’t unique, while a contract address is. Etherscan, Arbiscan, and Basescan display these fields for Ethereum, Arbitrum, and Base. Save the hash with the pool address for later exit reconciliation.

If bare BPT remains at 0, inspect the wrapped token or staking position. The concrete fallback is the wrapped token’s 1:1 balance.

Exit preparation starts before the first deposit

A clean Balancer exit starts with three saved facts: the chain, the pool contract, and the exact form holding your BPT claim.

Record whether the receipt sits in the wallet, a wrapped token, or a gauge. A full exit requires 100% of the BPT units that represent the position; a partial exit burns only the selected amount. Wrapped BPT must be burned back into BPT at 1:1 before a standard Router exit. A staked position first leaves its gauge so that the redeeming address holds the necessary BPT. These steps concern custody location, not the pool’s displayed dollar value, which moves with the underlying assets.

When the Router’s BPT allowance is short, Balancer v3 requests another approval. The BPT contract supports ERC-2612 permit data, so a compatible wallet can sign that approval while assembling the exit. Otherwise, approve the exact BPT amount or another deliberate limit.

Preserve the pool version, too. Balancer v2 exits use older Vault entry points, whereas v3 routes retail calls through its Router. A v3 proportional removal is one such path.

How do you redeem BPT for the underlying tokens?

You redeem BPT by choosing an output shape, setting minimum receipts or a maximum BPT spend, and confirming the Router’s removal transaction.

Proportional exit

Proportional removal burns an exact BPT amount and returns every registered pool token in the pool’s current proportions. Set a minimum amount for each output, because the Router accepts a minAmountsOut array in token-registration order. Burning the full wallet balance targets a full exit; burning 25% leaves 75% of the BPT claim with the same holder.

Single-token exit

Single-token exact-input removal burns an exact BPT amount and requires one selected token plus a minimum output. Single-token exact-output removal fixes the token amount received and caps the BPT spend. The first shape calculates the receipt from the submitted BPT; the second calculates the BPT required for the exact receipt. Both settle through one Router call.

Recovery Mode exposes a separate proportional route only while that pool mode is active. After confirmation, compare every returned token balance and the remaining receipt. A complete exit should leave 0 BPT in the redeemed address.

The Vault and Router settle the action under the hood

Once that is set, Balancer v3 settles each LP action through the Router and Vault, which turn token limits into minting or burning instructions.

Before execution, query functions estimate token inputs, BPT output, or exit receipts for the same sender and pool. The Router then submits exact amounts and boundary arrays to the Vault. For deposits, Permit2 transfers approved ERC-20 inputs into the Vault, the Vault settles balances, and the pool calculation mints BPT. For withdrawals, the Vault spends the Router’s BPT allowance, burns those units, and sends registered tokens back through the Router path. The WETH-as-ETH flag adds wrapping or unwrapping without changing the pool token itself. Hooks influence queries and execution, so sender context stays part of the calculation.

This ordering fixes the troubleshooting sequence: transaction status, chain, signed boundary, token movement, and BPT state. A quote without settlement produces no position; a successful full withdrawal consumes the chosen receipt and sends outputs to the recipient. For a direct unstaked full exit, the final checkpoint is a BPT balance of 0.