# Balancer V3 > Learn, integrate, and build on a programmable AMM ## Docs - [Build on Balancer](https://docs.balancer.fi/build/README.md): AMMs built on the Balancer protocol benefit from the security of the Balancer vault. This enables developers to utilize the well-developed Balancer AMM ecosystem, while the vault's optimized architecture streamlines the development process and allows teams to concentrate on their product. - [Data and Analytics overview](https://docs.balancer.fi/data-and-analytics/README.md): Balancer offers data about the protocol, accessible through various sources. This data is helpful for understanding the protocol's performance, usage, and trends. - [Developer Reference](https://docs.balancer.fi/developer-reference/README.md): For the most common use cases the APIs of interest will be the [Router](./contracts/router-api.md) or the [BatchRouter](./contracts/batch-router-api.md). - [Active Repositories](https://docs.balancer.fi/developer-reference/repositories.md): These repos are designed to be forked and used for new development by partners. They include the essentials for developing particular products, without the "noise" associated with the core repositories used by the Balancer team. - [Legacy Repositories](https://docs.balancer.fi/developer-reference/repositories.md): These are repos associated with past versions of Balancer or discontinued products. - [Repository Statistics](https://docs.balancer.fi/developer-reference/repositories.md): **V3 Repositories:** 10 core development + 7 templates = **17 total** - [Version Timeline](https://docs.balancer.fi/developer-reference/repositories.md): **V3 Repositories:** 10 core development + 7 templates = **17 total** - [Notes for Integrators](https://docs.balancer.fi/developer-reference/repositories.md): **V3 Repositories:** 10 core development + 7 templates = **17 total** - [Template Strategy](https://docs.balancer.fi/developer-reference/repositories.md): **V3 Repositories:** 10 core development + 7 templates = **17 total** - [Monorepo Structure](https://docs.balancer.fi/developer-reference/repositories.md): **V3 Repositories:** 10 core development + 7 templates = **17 total** - [Documentation Strategy](https://docs.balancer.fi/developer-reference/repositories.md): **V3 Repositories:** 10 core development + 7 templates = **17 total** - [Integration Guides](https://docs.balancer.fi/integration-guides/README.md): This sections contains useful guides for common actions such as adding/removing liquidity and making swaps using the SDK. Individuals are encouraged to contact our developers via [Discord](https://discord.balancer.fi/) to request further assistance. - [Architecture](https://docs.balancer.fi/concepts/core-concepts/architecture.md): The Balancer protocol architecture comprises three primary components, each strategically designed to enhance flexibility and minimize the intricacies involved in constructing pools. By distributing responsibilities across these components, Balancer simplifies pool development, empowering builders to focus on innovation rather than grappling with complex code. - [Balancer Pool Token Implementation](https://docs.balancer.fi/concepts/core-concepts/balancer-pool-tokens.md): Balancer Pool Tokens are tokens that represent ownership or shares in a Balancer pool. When users add liquidity to a Balancer pool by depositing tokens, they receive corresponding Balancer Pool Tokens in return. These tokens represent their proportional share of the liquidity pool. - [Concentrated Liquidity](https://docs.balancer.fi/concepts/core-concepts/concentrated-liquidity.md): In traditional automated market makers (AMMs), liquidity providers (LPs) deposit tokens across the entire possible price range: i.e., from $0 to ∞ for ETH/USDC. Yet in practice, most trading happens within a narrow price range that shifts relatively slowly along with the market price. That means most of the liquidity sits idle, earning no fees for LPs. - [Hooks](https://docs.balancer.fi/concepts/core-concepts/hooks.md): To get started building your own hook check out the [guide](/build/build-a-hook/extend-existing-pool-type.md). - [Introduction](https://docs.balancer.fi/concepts/core-concepts/introduction.md): Welcome to the Balancer Explained section, where we delve deep into the design and operation of Balancer v3. This section is perfect for anyone who wants a comprehensive understanding of the protocol's architecture, mechanics, and underlying principles. Whether you're curious about the inner workings or looking to grasp the finer details, you've come to the right place. - [Pool Role Permissions](https://docs.balancer.fi/concepts/core-concepts/pool-role-accounts.md): During pool registration `PoolRoleAccounts` are set immutably. These addresses have permission to change certain pool settings: - [Rate Providers](https://docs.balancer.fi/concepts/core-concepts/rate-providers.md): Rate Providers are contracts that provide an exchange rate between two assets. These exchange rates can come from any on-chain source, whether that may be an oracle, a ratio of queryable balances, or another calculation. - [Boosted Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/boosted-pool.md): Boosted Pools are a type of liquidity pool in which some or all of the tokens can generate yield. The yield-bearing tokens can constitute anywhere from 25% to 100% of the pool's total tokens. While the operation of Boosted Pools is not restricted to a specific trading algorithm, they often employ [Stable Math](/concepts/explore-available-balancer-pools/stable-pool/stable-math.html). This is due to the effectiveness of Stable Math in handling assets that are highly correlated. - [Governance](https://docs.balancer.fi/concepts/governance/README.md): Balancer is governed by veBAL token holders who vote on protocol changes through Snapshot. On-chain operations are executed by Balancer Onchain Limited through its service provider MAXYZ. This section documents all governance components and processes. - [BAL Token](https://docs.balancer.fi/concepts/governance/bal-token.md): Balancer Governance Token (BAL) is the core token behind the Balancer protocol. Alignment between governance token holders and protocol stakeholders is crucial for successful decentralized governance, and BAL tokens are the vehicle to drive this alignment. [veBAL](veBAL) is an extension of BAL and is used for voting in decentralized governance. - [Corporate Structure](https://docs.balancer.fi/concepts/governance/corporate-structure.md): As of [BIP-882](https://forum.balancer.fi/t/bip-882-transitioning-onchain-operations-of-the-balancer-dao-to-balancer-onchain-limited/6859), the Balancer ecosystem operates through a formal corporate structure that provides legal clarity, operational efficiency, and proper risk management while maintaining alignment with decentralized governance. - [Emergency subDAO](https://docs.balancer.fi/concepts/governance/emergency.md): The [Emergency DAO](https://dao.curve.fi/emergencymembers) is an idea pioneered by Curve that empowers a small group to "kill" pools and gauges in the event of malicious activity and/or potential loss of funds. The subDAO is further authorized to pause pools when needed. The Balancer emergency subDAO was established after the following [vote](https://vote.balancer.fi/#/proposal/0x63fab7ab9ef5b9579dabb82058b8ea309e39c766d435438b55fff8db7c1f69fd). - [Multisig](https://docs.balancer.fi/concepts/governance/multisig.md) - [Governance Process](https://docs.balancer.fi/concepts/governance/process.md): The Balancer Governance process has evolved through a number of BIPs as Balancer moves along on its quest towards decentralization. The most recent governance overhaul BIP at the time of this writing is [BIP-163](https://snapshot.org/#/balancer.eth/proposal/0xcd2cab0522b0e9a90ad40f93aca4505b17d60468224c22b69c4f9bd2bbd64e31). - [Protocol Fee Operations](https://docs.balancer.fi/concepts/governance/protocol-fees.md): This page describes how protocol fees are collected and processed through Balancer's safe infrastructure. For fee percentages, distribution splits, and core pool requirements, see the [Protocol Fee Model](../protocol-fee-model/protocol-fee-model.md). - [Snapshot](https://docs.balancer.fi/concepts/governance/snapshot.md): [Snapshot](https://snapshot.org/#/), a spinoff from the Balancer team, is an off-chain gasless multi-governance client with easy to verify and hard to contest results. - [Protocol Fee Model and Core Pool Framework](https://docs.balancer.fi/concepts/protocol-fee-model/protocol-fee-model.md): This documentation outlines Balancer's protocol fee model and core pool framework across Balancer v2 and v3, as established by governance with [BIP-734](https://snapshot.org/#/s\:balancer.eth/proposal/0x7a451385e49e341dce818927bf36aa35dfc6e42dabe328cb34e873c84fa452e4). - [Query Functions](https://docs.balancer.fi/concepts/router/queries.md): Queries provide the ability to simulate an operation and find its result without executing a transaction. [Balancer Routers](./overview.md#balancer-routers) provide a query for all state changing liquidity operations. An example of how this is useful can be seen when [setting slippage limits](/integration-guides/add-liquidity/sdk-tutorial.html#query-add-liquidity). - [The Vault](https://docs.balancer.fi/concepts/vault/README.md): The Vault is the core of the Balancer protocol; it is a smart contract that holds and manages all tokens in each Balancer pool. First introduced in Balancer v2, the vault architecture separates token accounting from pool logic, allowing for simplified pool contracts that focus on the implementation of their swap, add liquidity and remove liquidity logic. - [Add/Remove liquidity types](https://docs.balancer.fi/concepts/vault/add-remove-liquidity-types.md): Balancer protocol leverages the [Liquidity invariant approximation](/concepts/vault/liquidity-invariant-approximation.html) to provide a generalized solution for add and remove liquidity operations. This enables the Vault to implement complex `unbalanced` and `singleAsset` liquidity operations that all custom AMMs built on Balancer support by default. - [ERC4626 Liquidity Buffers](https://docs.balancer.fi/concepts/vault/buffer.md): Liquidity Buffers, an internal mechanism of the Vault, facilitate liquidity for pairs of an ERC4626 `asset` (underlying token like DAI) and the ERC4626 Vault Token (like waDAI). The Balancer Vault provides additional liquidity, enabling the entry into the ERC4626 Vault Token positions without the need to wrap or unwrap tokens through the lending protocol, thereby avoiding higher gas costs. - [ERC20MultiToken](https://docs.balancer.fi/concepts/vault/erc20-multi-token.md): ERC20MultiToken was inspired by [ERC1155](https://docs.openzeppelin.com/contracts/3.x/erc1155), but customized for Balancer v3. At a high level, it allows the [Balancer Vault](/concepts/vault) full control over Balancer Pool Token (BPT) accounting, enabling it to both mint and burn BPT directly. By centralizing both token and BPT accounting in the vault, Balancer v3 ensures atomic updates to critical pool state. In contrast to ERC1155, ERC20MultiToken allows Balancer Pool Tokens to be fully ERC20-compliant, supporting composability. - [Introduction](https://docs.balancer.fi/concepts/vault/flash-loans.md): Flash loans in Balancer V3 allow users to borrow assets without collateral, as long as the borrowed amount is repaid within the same transaction. This page explains the logic behind executing a flash loan and settling it correctly using the Balancer V3 Vault. - [Prerequisites](https://docs.balancer.fi/concepts/vault/flash-loans.md): Basic understanding of Solidity and smart contract development. - [Flash Loan Process](https://docs.balancer.fi/concepts/vault/flash-loans.md): Basic understanding of Solidity and smart contract development. - [Example Contract Implementation](https://docs.balancer.fi/concepts/vault/flash-loans.md): Basic understanding of Solidity and smart contract development. - [Liquidity Invariant Approximation](https://docs.balancer.fi/concepts/vault/liquidity-invariant-approximation.md): Adding and removing liquidity are considered liquidity operations in the context of this page. A Balancer pool allows adding and removing liquidity not only proportionally, but also in non-proportional or "unbalanced" ways. An unbalanced add or remove liquidity can be considered a combination of a proportional add or remove plus a swap. The vault must handle both scenarios with the same outcome for users and LPs, in order to ensure a fair settlement system. - [Swap fee](https://docs.balancer.fi/concepts/vault/swap-fee.md): A swap fee is charged for each swap, as well as on the non-proportional amounts in add/remove liquidity operations. When a pool is registered, the initial swap fee is passed as a parameter and stored as part of [the pool's configuration](https://github.com/balancer/balancer-v3-monorepo/blob/main/pkg/interfaces/contracts/vault/VaultTypes.sol#L28-L39). The swap fee is always charged on the amount in (i.e., on the given amount for EXACT\_IN, and the calculated amount for EXACT\_OUT). - [Token scaling](https://docs.balancer.fi/concepts/vault/token-scaling.md): Working with fixed-point math in Solidity presents a unique set of challenges that developers must navigate to ensure accurate and secure smart contract functionality. - [Token Types](https://docs.balancer.fi/concepts/vault/token-types.md): In line with Balancer's [yield-bearing native thesis](https://medium.com/balancer-protocol/balancer-the-yield-bearing-asset-thesis-f44489ba2deb), the vault supports a token specialization to provide built-in support for yield-bearing assets. - [Transient accounting](https://docs.balancer.fi/concepts/vault/transient-accounting.md): Transient accounting shifts the validation of accurate token accounting to the start and conclusion of a Vault interaction. This is achieved by initiating a transient state that monitors the debt and credit created during vault interactions. This transient state guarantees the atomic execution of operations within it and confirms the proper settlement of all debt and credit at the end of the execution, prior to exiting the transient state. - [Introduction](https://docs.balancer.fi/concepts/vault/yield-fee.md): Balancer Protocol Fees are collected by the Balancer Protocol on most operations, as a percentage of either pool swap fees or token yield. The Yield Fee is a specific type of Protocol fee that is applied to yield-bearing tokens, such as wstETH. The fee percentage is controlled by Balancer governance. - [Implementation](https://docs.balancer.fi/concepts/vault/yield-fee.md): as liquidity incentives for [core pools](https://forum.balancer.fi/t/bip-19-incentivize-core-pools-l2-usage/3329). This forms a key part of the [Yield Bearing Asset Thesis](https://medium.com/balancer-protocol/balancer-the-yield-bearing-asset-thesis-f44489ba2deb). - [APR Calculation](https://docs.balancer.fi/concepts/vebal-and-gauges/apr-calculation.md): Please note that for mainnet liquidity mining APRs can be boosted, therefore a range of 1x to 2.5x of the calculated APR is possible. - [veBAL Boost Calculation](https://docs.balancer.fi/concepts/vebal-and-gauges/boost-calculations.md): A range of 1x to 2.5x of the calculated APR is possible. A user may be interested in the minimum amount of veBAL for max boost, how their boost is calculated, and the maximum boost they can receive in cases where 2.5x is not attainable. - [Calculating Your Boost](https://docs.balancer.fi/concepts/vebal-and-gauges/boost-calculations.md): `l` = the liquidity a user will provide and stake in a gauge - [Calculating Maximum Boost](https://docs.balancer.fi/concepts/vebal-and-gauges/boost-calculations.md): `l` = the liquidity a user will provide and stake in a gauge - [Estimating Gauge Incentive APRs](https://docs.balancer.fi/concepts/vebal-and-gauges/estimating-gauge-incentive-aprs.md): Balancer introduced a new tokenomics system for the Balancer Governance Token (BAL) based on Curve's *ve* model. The system revolves around the following concepts: - [Gauges](https://docs.balancer.fi/concepts/vebal-and-gauges/gauges.md): The easiest way is to query `getPoolGauge(poolAddress)` on the [`LiquidityGaugeFactory`](https://etherscan.io/address/0x4E7bBd911cf1EFa442BC1b2e9Ea01ffE785412EC#code). - [How Many BPT in veBAL?](https://docs.balancer.fi/concepts/vebal-and-gauges/how-many-bpt-in-vebal.md): Are you trying value or determine underlying assets that are locked in veBAL? You'll need to query a few things from the [veBAL contract](https://etherscan.io/address/0xc128a9954e6c874ea3d62ce62b468ba073093f25#readContract). Most notably: - [veBAL](https://docs.balancer.fi/concepts/vebal-and-gauges/vebal.md): The `FeeDistributor` address is [`0x26743984e3357efc59f2fd6c1afdc310335a61c9`](https://etherscan.io/address/0x26743984e3357efc59f2fd6c1afdc310335a61c9#code) - [Extend an Existing Pool Type Using Hooks](https://docs.balancer.fi/build/build-a-hook/extend-existing-pool-type.md): *This section is for developers looking to extend an existing pool type with custom hooks. If you are looking to create a custom AMM with a novel invariant, start [here](/build/build-an-amm/create-custom-amm-with-novel-invariant.html).* - [Interacting With The Vault Using Hooks](https://docs.balancer.fi/build/build-a-hook/interacting-with-the-vault.md): The [Balancer Router](../../concepts/router/overview.md#balancer-routers) is typically the interface Externally Owned Accounts (EOAs) use to interact with the V3 Vault. While the Router uses Permit2 for token permissions, Hooks—being separate smart contracts—cannot sign these permissions. Instead, Hooks interact directly with the Vault. This section covers some common scenarios and usage patterns for Hooks. - [Create a custom Router](https://docs.balancer.fi/build/build-a-router/create-custom-router.md): A custom Router is a smart contract which interacts with the Balancer Vault and utilizes the Vaults function in unique combinations. The deployment of a custom Router is beneficial for various projects in the DeFi space. To name some verticals this could be: - [Balancer Routers](https://docs.balancer.fi/build/build-a-router/existing-routers.md): One of the major architectural changes from V2 to V3 is the introduction of Routers. In V2, the Vault was the "user interface" -- all swaps and liquidity operations were contract calls on the Vault itself. This design proved limiting when users wanted to, for instance, combine swaps and liquidity operations in a single call. Since the Vault is immutable, adding "new" operations required the use of relayers, or extensions to the already-complex pool designs. - [Create a custom AMM with a novel invariant](https://docs.balancer.fi/build/build-an-amm/create-custom-amm-with-novel-invariant.md): Balancer protocol provides developers with a modular architecture that enables the rapid development of custom AMMs. - [Deploy a Custom AMM Using a Factory](https://docs.balancer.fi/build/build-an-amm/deploy-custom-amm-using-factory.md): *This section is for developers looking to deploy a custom pool contract that has already been written. If you are looking to design a custom AMM with a novel invariant, start [here](/build/build-an-amm/create-custom-amm-with-novel-invariant.html).* - [Integrating a Custom AMM with Subgraph](https://docs.balancer.fi/build/build-an-amm/integrate-custom-amm-with-subgraph.md): For those interested in integrating a custom AMM with the Balancer toolkit, including its API and SDK, the first essential step involves integrating your AMM with the Subgraph. - [Balancer Subgraph](https://docs.balancer.fi/data-and-analytics/data-and-analytics/subgraph.md): The Balancer Subgraph indexes data on the Balancer smart contracts with a GraphQL interface. It updates data in response to function calls and contract events to maintain data. - [Active Permissions](https://docs.balancer.fi/developer-reference/authorizer/README.md): This section includes all of the permissions currently setup in the Authorizer for Balancer v3 deployments. The tables here are generated on the latest deployments repo state. - [Avalanche Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/avalanche.md) - [Base Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/base.md) - [Gnosis Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/gnosis.md) - [HyperEVM Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/hyperevm.md) - [Mainnet Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/mainnet.md) - [Monad Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/monad.md) - [Optimism Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/optimism.md) - [Plasma Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/plasma.md) - [Sepolia Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/sepolia.md) - [XLayer Authorizer Permissions](https://docs.balancer.fi/developer-reference/authorizer/xlayer.md) - [Batch Router API](https://docs.balancer.fi/developer-reference/contracts/batch-router-api.md): The Batch Router can be used to interact with Balancer onchain via state changing operations or used to query operations in an off-chain context. - [Buffer Router API](https://docs.balancer.fi/developer-reference/contracts/buffer-router-api.md): The Buffer Router can be used to interact with Balancer onchain via state changing operations or used to query operations in an off-chain context. - [Composite Liquidity Router API](https://docs.balancer.fi/developer-reference/contracts/composite-liquidity-router-api.md): The Composite Liquidity Router can be used to interact with Balancer onchain via state changing operations or used to query operations in an off-chain context. - [Error Codes](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): Balancer uses custom errors which provide a convenient and gas-efficient way to explain why an operation failed. Comments and context for the specific errors can be found in the tables below. - [governance-scripts](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| AlreadyInitialized | | The initialization can only be done once. | `0x0dc149f0` | \| PermissionNotGranted | | A permission required to complete the initialization was not granted. | `0xe5557e90` | \| VaultMismatch | | The Vault passed in as a sanity check doesn't match the Vault associated with the registry. | `0xc1faacc5` | - [interfaces](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| InvalidOraclePrice | | Oracle prices must be greater than zero to prevent zero or negative TVL values. | `0x1f8f95a0` | \| UnsupportedDecimals | | A price feed has decimals greater than the maximum allowed. | `0xd4f1d302` | - [oracles](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| TokenPriceTooSmall | | One of the token prices is too small. | `0x1d2fcef0` | - [pool-gyro](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| SupportsOnlyTwoTokens | | 2-CLP pools support 2 tokens only. | `0x34e77320` | - [pool-hooks](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| ExitFeeAboveLimit(uint256,uint256) | feePercentage: uint256, limit: uint256 | The exit fee cannot exceed the maximum allowed percentage. | `0x05631b5c` | \| PoolDoesNotSupportDonation | | The pool does not support adding liquidity through donation. | `0xdfcf485a` | - [pool-stable](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| AmplificationFactorTooHigh | | The amplification factor is above the maximum of the range (1 - 5000). | `0x9b80d390` | \| AmplificationFactorTooLow | | The amplification factor is below the minimum of the range (1 - 5000). | `0xab923323` | \| AmpUpdateAlreadyStarted | | Amplification update operations must be done one at a time. | `0x2f301e7e` | \| AmpUpdateDurationTooShort | | The amplification change duration is too short. | `0xcd6b022a` | \| AmpUpdateNotStarted | | Cannot stop an amplification update before it starts. | `0x4673a675` | \| AmpUpdateRateTooFast | | The amplification change rate is too fast. | `0x1c708b92` | - [pool-utils](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| StandardPoolWithCreator | | A pool creator was specified for a pool type that doesn't support it. | `0x61ee1764` | - [pool-weighted](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| WeightedPoolBptRateUnsupported | | `getRate` from `IRateProvider` was called on a Weighted Pool. | `0x18e79a20` | - [solidity-utils](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| CodeDeploymentFailed | | | `0xfef82207` | - [standalone-utils](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| InconsistentState(string,address) | contractName: string, contractAddress: address | A `_contractRegistry` entry has no corresponding `_contractInfo`. | `0x36a7ac0a` | - [vault](https://docs.balancer.fi/developer-reference/contracts/error-codes.md): \| Error | Arguments | Comment | Signature | \| --- | --- | --- | --- | \| ERC2612ExpiredSignature(uint256) | deadline: uint256 | Operation failed due to an expired permit signature. | `0x62791302` | \| ERC2612InvalidSigner(address,address) | signer: address, owner: address | Operation failed due to a non-matching signature. | `0x4b800e46` | - [Error selector index](https://docs.balancer.fi/developer-reference/contracts/error-signatures.md): Catalogue for decoding custom error signatures into their associated error names. Sorted by selector (4-byte). - [Hooks](https://docs.balancer.fi/developer-reference/contracts/hooks-api.md): Hooks have access to different data shared from the Vault. These allow a developer to build powerful execution logic when additionally utilizing the shared data. - [ProtocolFeesController](https://docs.balancer.fi/developer-reference/contracts/protocol-fee-controller-api.md): The protocol Fees controller is used to manage protocol and pool creator fees for the Vault. Like the authorizer, it can be updated through governance. - [Router API](https://docs.balancer.fi/developer-reference/contracts/router-api.md): The Router can be used to interact with Balancer onchain via state changing operations or used to query operations in an off-chain context. - [Security](https://docs.balancer.fi/developer-reference/contracts/security.md): This page will gradually be updated with more information. - [Unbalanced Add Via Swap Router API](https://docs.balancer.fi/developer-reference/contracts/unbalanced-add-via-swap-router-api.md): The Unbalanced Add Via Swap Router can be used to interact with Balancer onchain via state changing operations or used to query operations in an off-chain context. - [The Vault](https://docs.balancer.fi/developer-reference/contracts/vault-api.md): The [Router](../router/overview.html) is the primary entry-point for the Balancer Protocol. It exposes developer friendly interfaces for complex protocol interactions. - [Vault Constants (defined in code)](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): `_POOL_MINIMUM_TOTAL_SUPPLY` is set to 1e6, and corresponds to the "MINIMUM\_BPT" in v2. - [Vault Immutables (set on deployment)](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): This was set to 4 years. - [Protocol Fee Controller Constants](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): `MAX_PROTOCOL_SWAP_FEE_PERCENTAGE` was set to 50%, same as v2. - [Weighted Pool Constants](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): `_MIN_SWAP_FEE_PERCENTAGE` is set to 0.001%. - [Stable Pool Constants](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): `MIN_AMP` is 1; `MAX_AMP` is 50,000 (previously, and in v2, the limit was 5,000). These values ultimately arise from the math in Curve's StableSwap. Higher values "flatten" the price curve (i.e., have a greater range were the tokens trade at essentially 1:1), and lower values make it more sensitive to the balances, and behave more like the Weighted Math price curve. Higher liquidity and lower volatility pools can generally have higher Amplification Parameters. - [Router Constants](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): `_MAX_AMOUNT` is set to 2^128 - 1, or type(uint128).max in Solidity. - [Weighted/Stable Pool Immutables](https://docs.balancer.fi/developer-reference/contracts/vault-config.md): These were set to 4 years for both Weighted and Stable pools. - [SDK API Reference](https://docs.balancer.fi/developer-reference/sdk/API.md): This class provides functionality to: - [Balancer SDK](https://docs.balancer.fi/developer-reference/sdk/README.md): The Balancer SDK is a Typescript/Javascript library for interfacing with the Balancer protocol. This includes common contract interactions such as add/remove liquidity and swaps. - [Add Liquidity Guide](https://docs.balancer.fi/integration-guides/add-liquidity/overview.md): Balancer v3 supports several different [types of add liquidity operations](https://docs.balancer.fi/concepts/vault/add-remove-liquidity-types.html#add-remove-liquidity-types) - [Events](https://docs.balancer.fi/integration-guides/aggregators/events.md): All Vault Events are detailed in [IVaultEvents](https://github.com/balancer/balancer-v3-monorepo/blob/4b85fc30fbbffc3a0b7aa84e1dc0b63082d0768e/pkg/interfaces/contracts/vault/IVaultEvents.sol) - [Fetching Pool List](https://docs.balancer.fi/integration-guides/aggregators/fetching-pools-and-data.md): The [Balancer API](/data-and-analytics/data-and-analytics/balancer-api/balancer-api.md) can be used to retrieve a list of v3 pools and immutable data for calculating swaps. The API is running as a graphql server and is deployed at . - [Fetching Pool Data](https://docs.balancer.fi/integration-guides/aggregators/fetching-pools-and-data.md): Swap calculations require a combination of data that can be considered as immutable and dynamic. The API can provide both but dynamic data will be subject to a 5minute cache which may not provide the required accuracy. Pools also expose useful view functions that can be used to retrieve this data. These functions follow the format: - [Hooks Reference](https://docs.balancer.fi/integration-guides/aggregators/hooks-reference.md): Explore our [GitHub repository](https://github.com/balancer/balancer-maths) containing reference mathematical implementations, in Javascript and Python, for supported Balancer hook types. Designed to assist developers and integrators in understanding the underlying swap calculations, these implementations can be imported as a packages into your project or serve as a reference for your own implementation. - [Supported Hook Types](https://docs.balancer.fi/integration-guides/aggregators/hooks-reference.md): This uses the [onComputeDynamicSwapFeePercentage](/developer-reference/contracts/hooks-api.md#oncomputedynamicswapfeepercentage) hook. - [Integrating Balancer Liquidity For Swap Aggregators](https://docs.balancer.fi/integration-guides/aggregators/introduction.md): This secion serves as a central hub for aggregators seeking vital information and resources to seamlessly integrate with Balancer v3 liquidity. Should you require additional assistance or find any gaps in the provided information, our team is readily available to support you. - [Pool Maths Reference](https://docs.balancer.fi/integration-guides/aggregators/pool-maths-and-details.md): Explore our [GitHub repository](https://github.com/balancer/balancer-maths) containing reference mathematical implementations, in Javascript and Python, for supported Balancer pool types. Designed to assist developers and integrators in understanding the underlying swap calculations, these implementations can be imported as a packages into your project or serve as a reference for your own implementation. - [Supported Pool Types](https://docs.balancer.fi/integration-guides/aggregators/pool-maths-and-details.md): Pools that swap tokens by enforcing a Constant Weighted Product invariant. - [Swap Fees](https://docs.balancer.fi/integration-guides/aggregators/swap-fees.md): For more detailed information on Swap Fees please see the [Swap Fee Concepts](/concepts/vault/swap-fee.md) section. - [Useful Resources](https://docs.balancer.fi/integration-guides/aggregators/useful-resources.md): [Deployment Addresses](/developer-reference/contracts/deployment-addresses/mainnet.html) - [LBP Simulator](https://docs.balancer.fi/integration-guides/lbp-simulator/overview.md): The LBP Simulator is an interactive, client-side tool for modeling a Liquidity Bootstrapping Pool (LBP). It lets you configure a launch/divestment/buyback setup and watch how price, weights, and demand dynamics evolve over time. The goal is to make LBP mechanics more intuitive and to help teams explore tradeoffs before going on-chain. - [LBP Simulator User Guide](https://docs.balancer.fi/integration-guides/lbp-simulator/user-guide.md): The LBP Simulator lets you configure a Liquidity Bootstrapping Pool (LBP), model buy and sell pressure, and watch how prices, weights, and liquidity evolve over time. It also includes a simulated trading panel for swaps, limit orders, and TWAP. - [Price Impact](https://docs.balancer.fi/integration-guides/price-impact/price-impact.md): Price Impact refers to the change in the price of a token caused by a trade. It is particularly relevant when swapping tokens but is also indirectly connected to adding/removing liquidity. - [Remove Liquidity Guide](https://docs.balancer.fi/integration-guides/remove-liquidity/overview.md): Balancer v3 supports several different [types of remove liquidity operations](https://docs.balancer.fi/concepts/vault/add-remove-liquidity-types.html#remove-liquidity) - [Querying Swaps Onchain](https://docs.balancer.fi/integration-guides/swapping/querying-swaps-onchain.md): This guide explains how to query swap operations onchain using Balancer V3's querying mechanisms. You'll learn how to get accurate swap quotes without executing transactions, and how to handle scenarios where you need to query the same pool multiple times without state changes affecting subsequent queries. - [Swapping with Custom Paths with the Router](https://docs.balancer.fi/integration-guides/swapping/swapping-custom-paths-with-router.md): This guide illustrates the process of executing swaps through the router once swap paths have been established. The examples provided encompass both single and multi-path swap types, focusing on exactIn swaps. For additional information on exactOut swaps, please refer to the [Router API](../../developer-reference/contracts/router-api.md) documentation. - [Swapping with the Balancer Smart Order Router and SDK](https://docs.balancer.fi/integration-guides/swapping/swaps-with-sor-sdk.md): This guide showcases the capabilities of the Balancer Smart Order Router (SOR) accessible through the Balancer API, focusing on its ability to identify optimal swap paths for a given token pair. Subsequently, we explore the process of utilizing the SDK to seamlessly create and execute swap transactions. - [Onboarding Yield-bearing Assets](https://docs.balancer.fi/partner-onboarding/balancer-v2/onboard-yb-token.md): This guide outlines the process of onboarding yield-bearing assets to Balancer v2. To fully leverage Balancer's technology, you'll need to complete several key steps including token setup, rate provider implementation, pool creation, and optional gauge setup for BAL rewards. - [Setting Up a Partner Points Program Tag on the Balancer UI](https://docs.balancer.fi/partner-onboarding/balancer-v2/point-programs.md): This guide will walk you through the process of setting up a tag for your partner points program in the Balancer protocol. By following these steps, you'll be able to tag sets of pools in the Balancer API and frontend, allowing users to earn points for providing liquidity to specific pools. - [Token Whitelisting](https://docs.balancer.fi/partner-onboarding/balancer-v2/token-whitelisting.md): This guide explains the process of whitelisting tokens on Balancer and important security considerations. - [Onboarding to Balancer v2](https://docs.balancer.fi/partner-onboarding/balancer-v2/v2-overview.md): Balancer v2 has been a core pillar of DeFi since 2021. By leveraging innovative pool types, Balancer v2 has attracted liquidity in the liquid staking token (LST) and liquid restaking token (LRT) sector. - [Pool Creation](https://docs.balancer.fi/partner-onboarding/balancer-v3/pool-creation.md): This guide will help you understand pool configuration options and how to use the [v3 pool creation UI](https://pool-creator.balancer.fi/v3) - [Onboarding to Balancer v3](https://docs.balancer.fi/partner-onboarding/balancer-v3/v3-overview.md): Balancer v3 introduces a simplified and more efficient AMM infrastructure, optimized for scalability and developer experience. The v3 architecture brings native support for yield-bearing tokens, 100% boosted pools, and a flexible hooks system for custom pool extensions. - [Core Pools](https://docs.balancer.fi/partner-onboarding/onboarding-overview/core-pools.md): Core pools are a fundamental concept in Balancer's tokenomics model, designed to align token emissions with pool performance and fee generation. This document outlines the requirements and benefits of core pools across both Balancer v2 and v3. - [Gauge Onboarding](https://docs.balancer.fi/partner-onboarding/onboarding-overview/gauge-onboarding.md): A gauge is a staking contract that enables token rewards to flow to liquidity providers of a pool. Gauges are required for **both** BAL emissions and secondary reward token incentives. Pools do not automatically have gauges—they must be created first. - [Introduction](https://docs.balancer.fi/partner-onboarding/onboarding-overview/incentive-management.md): The Balancer ecosystem is utilizing a modified version of Curve's vyper gauge infrastructure. Here, we outline how you can utilize our staking gauge system. We cover both how you can apply for a veBAL gauge to receive BAL rewards and how secondary reward programs can be set up. - [Partner Onboarding](https://docs.balancer.fi/partner-onboarding/onboarding-overview/introduction.md): From product details to step-by-step integration guides, this documentation provides partners with everything they need to onboard into the Balancer Ecosystem. - [Rate Providers](https://docs.balancer.fi/partner-onboarding/onboarding-overview/rate-providers.md): Rate providers are contracts that provide an exchange rate between two assets. For example, the rate of stETH to wstETH. If a pool is created with tokens that use unreviewed rate providers, it will not show on [balancer.fi](https://balancer.fi/pools) - [Voting Incentive Marketplaces](https://docs.balancer.fi/partner-onboarding/onboarding-overview/voting-markets.md): The Balancer community voted in favor of centralizing voting incentives to StakeDAOs Votemarket with [BIP-903](https://forum.balancer.fi/t/bip-903-transition-core-pool-incentive-program-to-stake-dao-s-votemarket-v2/6928) - [Batch Swap](https://docs.balancer.fi/tools/core/batch-swap.md) - [Pools](https://docs.balancer.fi/tools/core/pools.md) - [Smart Order Router](https://docs.balancer.fi/tools/core/smart-order-router.md) - [Overview](https://docs.balancer.fi/concepts/core-concepts/bpt-oracles/bpt-oracles-contracts.md): We have implemented oracles for both Weighted and Stable Balancer pools, as well as Gyro E-CLPs. These are in the `oracles` package: `WeightedLPOracle`, `StableLPOracle`, `EclpLPOracle`, and associated factories. - [Numerical example](https://docs.balancer.fi/concepts/core-concepts/bpt-oracles/bpt-oracles-example.md): Consider a Stable Pool containing USDC and USDT, where USDT has slightly de-pegged (say, to 0.98). - [Price Oracles for BPT as Collateral](https://docs.balancer.fi/concepts/core-concepts/bpt-oracles/bpt-oracles.md): Liquidity provider (LP) tokens represent proportional ownership in a pool of assets. In the Balancer ecosystem, these are known as BPT (Balancer Pool Tokens). When users add liquidity to a Balancer pool by depositing tokens, they receive corresponding Balancer Pool Tokens in return. These tokens represent their proportional share of the liquidity pool. - [Gyroscope 2-CLP Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/gyroscope-pool/gyro-2clp.md): These pools use the following invariant: (x + a)(y + b) = $L^2$. - [Gyroscope E-CLP Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/gyroscope-pool/gyro-eclp.md): Elliptic CLPs, or E-CLPs, allow trading along the curve of an ellipse. Similar to other CLPs, E-CLPs are designed to concentrate liquidity within price bounds. However, E-CLP liquidity is much more flexible. Just as 2-CLP pools concentrate liquidity over a range, vs. spreading it uniformly over the entire (infinite) price range, E-CLP pools can focus liquidity asymmetrically over the already restricted range defined by the alpha and beta parameters. - [Fixed Price LBP](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/fixed-price-lbp.md): A **Fixed Price LBP** is a Liquidity Bootstrapping Pool that keeps a **constant exchange rate** between the project token and the reserve token for the whole sale. Unlike standard LBPs, there is no scheduled weights changes. - [Liquidity Bootstrapping Pools (LBPs)](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/liquidity-bootstrapping-pool.md): Balancer offers two LBP variants: - [Token Buybacks](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/token-buybacks.md): The same LBP mechanism can be used to support **accumulation** - buying the project token. - [Token Launches](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/token-launches.md): The Liquidity Bootstrapping Pool (LBP) is the standard primitive for initial token distribution. The LBP utilizes time-dependent weights to facilitate fair price discovery and capital efficiency. - [Treasury Diversification](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/treasury-diversification.md): LBPs can help treasuries and DAOs enter or exit large positions with reduced market impact. - [AutoRange Pool Math](https://docs.balancer.fi/concepts/explore-available-balancer-pools/reclamm-pool/reclamm-pool-math.md): The AutoRange Pool is based on a "constant product," essentially equivalent to standard weighted math (with a clever redefinition of the token balances). The idea is to concentrate liquidity by adding price bounds to the constant product curve using virtual balances: $L = (R\_a + V\_a)(R\_b + V\_b)$, where $R\_a$ and $R\_b$ are the real balances of the token, and $V\_a$ and $V\_b$ are the virtual balances of the token. - [Calculation of Swap Result](https://docs.balancer.fi/concepts/explore-available-balancer-pools/reclamm-pool/reclamm-pool-math.md): First, if $R\_a$ or $R\_b$ are 0, we know that pool centeredness is 0. - [AutoRange Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/reclamm-pool/reclamm-pool.md): AutoRange Pools are **fungible concentrated liquidity pools** that focus liquidity within a predefined price range, allowing LPs to earn greater fees with less capital—especially when the market price remains within that range. This concentration is initialized with a **target price** and **range bounds**, enabling the pool to deliver capital efficiency over traditional constant-product models. - [Stable Math](https://docs.balancer.fi/concepts/explore-available-balancer-pools/stable-pool/stable-math.md): Stable Math is designed to allow for swaps between any assets that have the same price, or are "pegged" to the same asset. The most common examples are stablecoins that track US Dollars (DAI, USDT, USDC), and assets that track the price of Bitcoin (WBTC, renBTC, sBTC). Prices are determined by the pool balances, the *amplification parameter*, and amounts of the tokens that are being swapped. - [Stable Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/stable-pool/stable-pool.md): Stable Pools are designed for assets that are either expected to consistently swap at near parity, or at a known exchange rate. Stable Pools use [Stable Math](./stable-math.md) (based on StableSwap, popularized by Curve) which allows for swaps of significant size before encountering substantial price impact, vastly increasing capital efficiency for like-kind and correlated-kind swaps. - [StableSurge Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/stable-pool/stable-surge-pool.md): StableSurge Pools are a type of Stable Pool designed for assets that usually trade at nearly the same value or have a predictable exchange rate. What makes StableSurge Pools different is that they use a special feature—called a hook—to automatically adjust the swap fee based on how balanced the pool is during a trade. - [StableSurge Math](https://docs.balancer.fi/concepts/explore-available-balancer-pools/stable-pool/stablesurge-math.md): StableSurge Math leverages [Stable Math](./stable-math.md) for the pool invariant, and the hook itself only affects the swap fee. The swap fee is calculated linearly based on the absolute delta values of pool token balances based on an add, remove, or swap event, resulting in a fee increase when the surge criteria are met. - [80/20 Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/80-20-pool.md): page coming soon. - [Impermanent Loss](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md): Impermanent Loss, sometimes referred to as divergent loss, is simply the opportunity cost of adding liquidity into an AMM pool vs. holding the individual tokens. - [50/50 Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md): We will start with a simple 50/50 pool featuring COMP/WETH. We want to deposit $5,000 worth of each token, for a total value of $10,000. At initial investment time, WETH is priced at $2,000, and COMP is $250, so we deposit 2.5 WETH and 20 COMP. - [80/20 Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md): Here we will examine how disproportionate pool weights affect the calculation of impermanent loss, using the same scenario described above, but for an 80/20 vs. a 50/50 pool. - [Multi-token Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md): Balancer's multi-token pools are one of our unique features. Below is an example of how impermanent loss on one of these pools can occur, including details on volatility and stable coins. - [Weighted Math](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-math.md): Weighted Math is designed to allow for swaps between any assets whether or not they have any price correlation. Prices are determined by the pool balances, pool weights, and amounts of the tokens that are being swapped. - [Weighted Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-pool.md): Weighted Pools are an extension of the classical $x \* y = k$ AMM pools popularized by Uniswap v1. Weighted Pools use [Weighted Math](./weighted-math.md), which makes them great for general cases, including tokens that don't necessarily have any price correlation (ex. DAI/WETH). Unlike pools in other AMMs that only provide 50/50 weightings, Balancer Weighted Pools enable users to build pools with more than two tokens and custom weights, such as pools with 80/20 or 60/20/20 weights. - [veBAL FAQ](https://docs.balancer.fi/concepts/governance/veBAL/FAQ.md): When you provide liquidity into a Balancer pool, you take out an ERC-20 token we call a "Balancer Pool Token", or BPT for short. In veBAL, the used BPT is from a B-80BAL-20WETH pool. - [veBAL](https://docs.balancer.fi/concepts/governance/veBAL/README.md): veBAL (vote-escrow BAL) is a vesting system based on [Curve's veCRV mechanism](https://curve.readthedocs.io/dao-vecrv.html) which locks 80/20 BAL/WETH Balancer Pool Tokens for a maximum of 1 year. The veBAL and Gauge system is designed to promote long-term token-holder alignment and facilitate fair protocol fee distribution. - [Balancer API](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/balancer-api.md): Balancer's API exposes data on Balancer's smart contracts accessible via graphql. The API is running as a graphql server and is deployed at . - [Examples](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/balancer-api.md): Pools - [Get a v2 pool's details including APRs](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/pool-details-with-apr.md) - [Get swap events for one or more pools](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/pool-swap-events.md): This query returns all Swap events for the two pools in the filter. One is a CowAMM pool and the other a v2 weighted pool. As they have different event types, we also use the expanded `GqlPoolSwapEventCowAmm` and `GqlPoolSwapEventV3` types to get CowAMM and "standard" pool specific swap datas. - [Query to find top 10 pools ordered by TVL](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/pools-top-ordered-tvl.md): This query also returns the pools APRs and staking gauge. One of the conventions is to use "dynamicData" for querying changing parts of the state. - [Query all pools on Arbitrum and Avalanche that have TVL greater than $10k](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/pools-with-tvl.md) - [Swap - Query the Smart Order Router (SOR)](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/swap-query-sor.md): In this example we query for best paths to swap 1WETH to USDC. Note the use of human scaled amount. - [Get add and removes for a user](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/user-pool-add-remove.md): This query returns all add and removes of a specific user for a specific pool. It also returns the token amounts with which the user has added or removed liquidity from the pool. - [Get pool balances for a user](https://docs.balancer.fi/data-and-analytics/data-and-analytics/balancer-api/user-pool-balance.md): This query returns all pools that the user has a balance. We differentiate between staked and wallet balances. Wallet balances mean that the user holds the BPT in his wallet. Staked balances mean that the BPT is staked in a supported service, such as a gauge or on Aura. - [Dashboards](https://docs.balancer.fi/data-and-analytics/data-and-analytics/dune/dashboards.md): **Balancer Labs' data team** works on building dashboards where internal and external stakeholders can gather as much information as possible on the protocol. - [Overview](https://docs.balancer.fi/data-and-analytics/data-and-analytics/dune/overview.md): Welcome to Balancer's data analytics powered by Dune! - [Spells](https://docs.balancer.fi/data-and-analytics/data-and-analytics/dune/spells.md): Unlock the power of Balancer data with our meticulously crafted Dune Spells! Balancer Labs' data team is dedicated to the relentless pursuit of excellence, continuously refining and updating our Dune Spells to deliver the most accurate, insightful, and up-to-date analytics for the Balancer community. - [Overview](https://docs.balancer.fi/developer-reference/contracts/abi/README.md): You can find relevant Abis here: - [Batch Router ABI](https://docs.balancer.fi/developer-reference/contracts/abi/batch-router.md) - [Buffer Router ABI](https://docs.balancer.fi/developer-reference/contracts/abi/buffer-router.md) - [Composite Liquidity Router ABI](https://docs.balancer.fi/developer-reference/contracts/abi/composite-liquidity-router.md) - [Router ABI](https://docs.balancer.fi/developer-reference/contracts/abi/router.md) - [Unbalanced Add Via Swap Router ABI](https://docs.balancer.fi/developer-reference/contracts/abi/unbalanced-add-via-swap-router.md) - [Arbitrum Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/arbitrum.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Avalanche Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/avalanche.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Base Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/base.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Gnosis Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/gnosis.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [HyperEVM Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/hyperevm.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Mainnet Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/mainnet.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Monad Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/monad.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Optimism Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/optimism.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Plasma Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/plasma.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Polygon Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/polygon.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Sepolia Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/sepolia.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [XLayer Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/xlayer.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [Zkevm Deployment Addresses](https://docs.balancer.fi/developer-reference/contracts/deployment-addresses/zkevm.md): For more information on specific deployments as well as changelogs for different contract versions, please see the [deployment tasks](https://github.com/balancer/balancer-deployments/tree/master/v3/tasks). - [V3 Pool Deployments](https://docs.balancer.fi/developer-reference/contracts/deployment-history/pools.md): Here is the current list of official Balancer Pool deployments: - [V3 Router Deployments](https://docs.balancer.fi/developer-reference/contracts/deployment-history/routers.md): Here is the current list of official Balancer Router deployments: - [Boosted Pools](https://docs.balancer.fi/partner-onboarding/onboarding-overview/products/boostedpools.md): Boosted Pools represent a significant evolution in DeFi yield generation, combining the benefits of DEX liquidity provision and lending market yields in a single position. These pools maximize capital efficiency while maintaining a simple, passive user experience. - [Hosting of Liquid Staking and Restaking Tokens](https://docs.balancer.fi/partner-onboarding/onboarding-overview/products/lstandlrt.md): Balancer is the most attuned decentralised financial technology layer to host yield-bearing assets. Yield-bearing tokens such as LSTs and interest-bearing stablecoins offer an additional layer of efficiency compared to their vanilla counterparts. These tokenised assets allow users to gain exposure to both on-chain and off-chain interest rates, compounded within a single token. Compared to traditional AMM design, Balancer uses a variety of new concepts to leverage yield-bearing token liquidity while offering optimal results to liquidity providers (LPs) and traders by optimizing trade routes and exchange rates between assets. This is achieved by utilizing three core components: - [Resources](https://docs.balancer.fi/partner-onboarding/onboarding-overview/products/lstandlrt.md): [Rate provider](../rate-providers.md) technology - [Governance Tokenomics](https://docs.balancer.fi/partner-onboarding/onboarding-overview/products/ve8020.md): Single Asset staking is an outdated governance tokenomics model that reduces a tokens liquidity, increases token volatility and slippage, Incentivizes mercenary capital, and creates fragmented and expensive incentive programs. ve8020 combines the flexibility of asymmetric weighted pools with the efficiency of vote-escrowed mechanics to unlock the next evolution of DAO Governance tokenomics.