diff --git a/docs/build-a-custom-amm/build-an-amm/create-custom-amm-with-novel-invariant.md b/docs/build-a-custom-amm/build-an-amm/create-custom-amm-with-novel-invariant.md index ac372632..67741be2 100644 --- a/docs/build-a-custom-amm/build-an-amm/create-custom-amm-with-novel-invariant.md +++ b/docs/build-a-custom-amm/build-an-amm/create-custom-amm-with-novel-invariant.md @@ -401,7 +401,7 @@ These settings get passed into the [pool registration](/developer-reference/cont When deploying your pool, there are three required steps that must be taken, in order: -1. Deploy the pool contract to the desired network, ensuring that the correct `vault` is provided. The address of the deployed contract will be needed in step `2` and `3`. Offical deployments can be found [here](/reference/contracts/). +1. Deploy the pool contract to the desired network, ensuring that the correct `vault` is provided. The address of the deployed contract will be needed in step `2` and `3`. Official deployments can be found [here](/reference/contracts/). 2. Call [`vault.registerPool()`](https://github.com/balancer/balancer-v3-monorepo/blob/main/pkg/interfaces/contracts/vault/IVaultExtension.sol#L77). Register will identify the pool with the vault and allow you to define token config, hook support, pause windows, and custom liquidity operation support. 3. Call [`vault.initialize()`](https://github.com/balancer/balancer-v3-monorepo/blob/main/pkg/interfaces/contracts/vault/IVaultExtension.sol#L110). Initialize will perform any pool specific setup and seed the pool with initial liquidity, enabling swaps and normal liquidity operations. diff --git a/docs/concepts/core-concepts/pool-creator-fee.md b/docs/concepts/core-concepts/pool-creator-fee.md index 2837d7ab..038d7e71 100644 --- a/docs/concepts/core-concepts/pool-creator-fee.md +++ b/docs/concepts/core-concepts/pool-creator-fee.md @@ -4,7 +4,7 @@ title: Pool Creator Fee --- ## Pool Creator Fee -Introducing the Pool Creator Fee—a groundbreaking feature within the Balancer Protocol that revolutionizes the way developers engage with liquidity pools. With this innovative concept, developers of specific pools have the opportunity to earn a share of the swap fee & yield fee as revenue, incentivizing the creation of successful and thriving pools. In the following section, we delve into the details of this exciting feature, exploring how it works and its implications for pool creators. +Introducing the Pool Creator Fee—a groundbreaking feature within the Balancer Protocol that revolutionizes the way developers engage with liquidity pools. With this innovative concept, developers of specific pools have the opportunity to earn a share of the swap fee & yield fee as revenue, incentivising the creation of successful and thriving pools. In the following section, we delve into the details of this exciting feature, exploring how it works and its implications for pool creators. ## Implementation diff --git a/docs/concepts/explore-available-balancer-pools/README.md b/docs/concepts/explore-available-balancer-pools/README.md index 7a31461a..d70d883c 100644 --- a/docs/concepts/explore-available-balancer-pools/README.md +++ b/docs/concepts/explore-available-balancer-pools/README.md @@ -11,7 +11,7 @@ Let's explore some of the diverse pool types within the Balancer Protocol, each - [80/20 Pool](./weighted-pool/80-20-pool.md): An optimised version of the Weighted Pool with set weights of 80%/20%. The perfect fit for achieving liquidity of governance tokens. - [Stable Pools](./stable-pool/stable-pool.md): Stable Pools are optimal for assets expected to consistently trade at near parity or with a known exchange rate. - [Boosted Pool](./boosted-pool.md): Boosted Pools are designed to allow for greater capital efficiency, deeper liquidity, and increased yield for Liquidity Providers. -- [Liquidity Bootstrapping pools](./liquidity-bootstrapping-pool.md): Liquidity Bootstrapping Pools (LBPs) are pools that can dynamically change token weighting. LBPs create sell pressure and fair market advantages. Used very succesfully for fair token launches. +- [Liquidity Bootstrapping pools](./liquidity-bootstrapping-pool.md): Liquidity Bootstrapping Pools (LBPs) are pools that can dynamically change token weighting. LBPs create sell pressure and fair market advantages. Used very successfully for fair token launches. Every pool type is associated with its own Factory contract, facilitating the creation of new pools. Experienced developers can find the factory deployment addresses through [this resource](../../developer-reference/contracts/deployment-addresses/mainnet.md). For further assistance, individuals are encouraged to contact our developers via [Discord](https://discord.balancer.fi/). diff --git a/docs/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md b/docs/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md index 60ee4907..125975a9 100644 --- a/docs/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md +++ b/docs/concepts/explore-available-balancer-pools/weighted-pool/impermanent-loss.md @@ -112,7 +112,7 @@ This shows that even large impermanent losses can always be reversed through sub # 80/20 Pools -Here we will examine how disproporionate pool weights affect the calculation of impermanent loss, using the same scenario described above, but for an 80/20 vs. a 50/50 pool. +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. #### COMP WETH 80/20 diff --git a/docs/concepts/vault/buffer.md b/docs/concepts/vault/buffer.md index 99f7c5ab..8465bb1b 100644 --- a/docs/concepts/vault/buffer.md +++ b/docs/concepts/vault/buffer.md @@ -64,7 +64,7 @@ function removeLiquidityFromBuffer( ## Using a buffer to swap. -The swapper has the responsibility to decide whether a specific swap route should use Buffers by indicating if a given `pool` is a buffer. Rember: You can always use a buffer even it is does not have liquidity (instead it will simply wrap or unwrap). This is done by setting the boolean entry in the `SwapPathStep` struct. +The swapper has the responsibility to decide whether a specific swap route should use Buffers by indicating if a given `pool` is a buffer. Remember: You can always use a buffer even it is does not have liquidity (instead it will simply wrap or unwrap). This is done by setting the boolean entry in the `SwapPathStep` struct. The `pool` param in this particular case is the wrapped Tokens entrypoint. Meaning the address where a user would call deposit in. In the case of Aave it would the waUSDC. ``` solidity diff --git a/docs/concepts/vault/token-scaling.md b/docs/concepts/vault/token-scaling.md index 98ef5b92..7e966d6a 100644 --- a/docs/concepts/vault/token-scaling.md +++ b/docs/concepts/vault/token-scaling.md @@ -77,7 +77,7 @@ On pool [register](https://github.com/balancer/balancer-v3-monorepo/blob/main/pk To define a token with a rate, specify the token type as `TokenType.WITH_RATE`. Additionally, you must provide a `rateProvider` address that implements the [`IRateProvider`](https://github.com/balancer/balancer-v3-monorepo/blob/main/pkg/interfaces/contracts/vault/IRateProvider.sol) interface. Refer to [Token types](/concepts/vault/token-types.html) for a detailed explanation on each token type. ### Rate scaling usage -Rate scaling is used on every `swap`, `addLiqudity` and `removeLiquidity` operation. If the token was registered as `TokenType.WITH_RATE`, an external call to the Rate Provider is made via `getRate`. If the `TokenType.STANDARD` was selected, the rate is always `1e18`. These rates are used to upscale the `amountGiven` in the Vault primitives. +Rate scaling is used on every `swap`, `addLiquidity` and `removeLiquidity` operation. If the token was registered as `TokenType.WITH_RATE`, an external call to the Rate Provider is made via `getRate`. If the `TokenType.STANDARD` was selected, the rate is always `1e18`. These rates are used to upscale the `amountGiven` in the Vault primitives. :::info 1. With a swap, the known token amount is given in native decimals as [`amountGivenRaw`](https://github.com/balancer/balancer-v3-monorepo/blob/main/pkg/interfaces/contracts/vault/VaultTypes.sol#L183) 2. [`AmountGivenRaw` is upscaled](https://github.com/balancer/balancer-v3-monorepo/blob/main/pkg/vault/contracts/Vault.sol#L303-L320) diff --git a/docs/concepts/vebal-and-gauges/apr-calculation.md b/docs/concepts/vebal-and-gauges/apr-calculation.md index 0a209c64..e32debdd 100644 --- a/docs/concepts/vebal-and-gauges/apr-calculation.md +++ b/docs/concepts/vebal-and-gauges/apr-calculation.md @@ -5,7 +5,7 @@ description: Formula to calculate the annual percentage rate (APR) of gauge ince # APR Calculation ::: info -Please note that for mainnet liquidity mining APRs are boostable, therefore a range of 1x to 2.5x of the calculated APR is possible. +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. ::: $$ diff --git a/docs/developer-reference/README.md b/docs/developer-reference/README.md index a5636e22..b334bdc7 100644 --- a/docs/developer-reference/README.md +++ b/docs/developer-reference/README.md @@ -4,7 +4,7 @@ order: 0 --- # Developer Reference -For the most common usecases the APIs of interest will be the [Router](./contracts/router-api.md) or the [BatchRouter](./contracts/batch-router-api.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). We also provide a [JS/TS SDK](./sdk/README.md) to assist with interacting with the Balancer Protocol. diff --git a/docs/developer-reference/contracts/error-codes.md b/docs/developer-reference/contracts/error-codes.md index a80fa044..386f2d12 100644 --- a/docs/developer-reference/contracts/error-codes.md +++ b/docs/developer-reference/contracts/error-codes.md @@ -142,8 +142,8 @@ Balancer uses custom errors which provide a convenient and gas-efficient way to ## StableMath | Error | Comment | | ----------------------------- | ----------------------------------------------- | -| StableInvariantDidntConverge()| The iterations to calculate the invariant didn't converge | -| StableGetBalanceDidntConverge()| The iterations to calculate the balance didn't converge | +| StableInvariantDidNotConverge()| The iterations to calculate the invariant didn't converge | +| StableGetBalanceDidNotConverge()| The iterations to calculate the balance didn't converge | ## Weighted diff --git a/docs/developer-reference/contracts/security.md b/docs/developer-reference/contracts/security.md index 939236e3..27e45360 100644 --- a/docs/developer-reference/contracts/security.md +++ b/docs/developer-reference/contracts/security.md @@ -13,7 +13,7 @@ As the development of Balancer V3 is ongoing, this page will gradually be update For more information of Balancer's Bug Bounty program, please visit our [Immunefi page](https://immunefi.com/bounty/balancer/). ::: warning -**Bounties only apply to protcol smart contracts**. Bug reports pertaining to Balancer's web interfaces, both in terms of UI/UX or servers/infrastructure, are not eligible. +**Bounties only apply to protocol smart contracts**. Bug reports pertaining to Balancer's web interfaces, both in terms of UI/UX or servers/infrastructure, are not eligible. ::: For security reports outside of the scope of the bug bounty program, please reach out via security@balancer.finance @@ -32,11 +32,11 @@ The core contracts that make up the Balancer V2 Protocol, such as the Vault and On the 10th [of October 2022](https://medium.com/balancer-protocol/balancer-and-certora-launch-security-accelerator-420d3b839a37), Balancer launched the Balancer Certora Security Accelerator in partnership with [Certora](https://www.certora.com/). The Security Accelerator helps projects building on Balancer increase their code security. -The Accelerator provides code reviews and grants access to Certora’s formal verification Prover. This alignment strengthens the soundness of the code base and streamlines the go-to-market process for projects building on Balancer. +The Accelerator provides code reviews and grants access to Certora's formal verification Prover. This alignment strengthens the soundness of the code base and streamlines the go-to-market process for projects building on Balancer. The Balancer x Certora Security Accelerator offers the following benefits: - Two weeks of manual code review by Certora engineers familiar with Balancer’s codebase -- Set up and introduction of Certora’s formal verification Prover -- $10.000 USD worth of credits for Certora’s formal verification Prover +- Set up and introduction of Certora's formal verification Prover +- $10.000 USD worth of credits for Certora's formal verification Prover - Integration assistance by Balancer on code functionality and business logic diff --git a/docs/developer-reference/sdk/API.md b/docs/developer-reference/sdk/API.md index 1d7572c5..99ff1f99 100644 --- a/docs/developer-reference/sdk/API.md +++ b/docs/developer-reference/sdk/API.md @@ -9,14 +9,14 @@ heroImage: /images/backgrounds/purple.png ## AddLiquidity This class provides functionality to: -* Perform on-chain queries to see the result of an addLiqudity operation +* Perform on-chain queries to see the result of an addLiquidity operation * Build an addLiquidity transaction, with slippage, for a consumer to submit * Supported add types: SingleToken, Unbalanced, Proportional * Supports Balancer V2 & V3 ### Example -See the [addLiqudity guide](../../integration-guides/guides/add-liquidity-to-pool.md) and the [addLiqudity example](https://github.com/balancer/b-sdk/tree/main/examples/addLiquidity/addLiquidity.ts). +See the [addLiquidity guide](../../integration-guides/guides/add-liquidity-to-pool.md) and the [addLiquidity example](https://github.com/balancer/b-sdk/tree/main/examples/addLiquidity/addLiquidity.ts). ### Constructor @@ -42,7 +42,7 @@ query( | Name | Type | Description | | ------------- | ------------- | ------------ | | input | [AddLiquidityInput](https://github.com/balancer/b-sdk/tree/main/src/entities/addLiquidity/types.ts#L38) | User defined inputs | -| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liqudity is being added to | +| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liquidity is being added to | **Returns** @@ -79,14 +79,14 @@ ___ ## RemoveLiquidity This class provides functionality to: -* Perform on-chain queries to see the result of an removeLiqudity operation +* Perform on-chain queries to see the result of an removeLiquidity operation * Build a removeLiquidity transaction, with slippage, for a consumer to submit * Supported remove types: Unbalanced, SingleTokenExactOutInput, SingleTokenExactInInput, Proportional * Supports Balancer V2 & V3 ### Example -See the [removeLiqudity guide](../../integration-guides/guides/remove-liquidity-from-pool.md) and the [removeLiqudity example](ttps://github.com/balancer/b-sdk/tree/main/examples/removeLiquidity/removeLiquidity.ts). +See the [removeLiquidity guide](../../integration-guides/guides/remove-liquidity-from-pool.md) and the [removeLiquidity example](ttps://github.com/balancer/b-sdk/tree/main/examples/removeLiquidity/removeLiquidity.ts). ### Constructor @@ -112,7 +112,7 @@ query( | Name | Type | Description | | ------------- | ------------- | ------------ | | input | [RemoveLiquidityInput](https://github.com/balancer/b-sdk/tree/main/src/entities/removeLiquidity/types.ts#L52) | User defined inputs | -| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liqudity is being removed from | +| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liquidity is being removed from | **Returns** @@ -139,7 +139,7 @@ queryRemoveLiquidityRecovery( | Name | Type | Description | | ------------- | ------------- | ------------ | | input | [RemoveLiquidityRecoveryInput](https://github.com/balancer/b-sdk/tree/main/src/entities/removeLiquidity/types.ts#L47) | User defined inputs | -| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liqudity is being removed from | +| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liquidity is being removed from | **Returns** @@ -227,7 +227,7 @@ Promise [ExactInQueryOutput](https://github.com/balancer/b-sdk/tree/main/src/entities/swap/types.ts#L44) [ExactOutQueryOutput](https://github.com/balancer/b-sdk/tree/main/src/entities/swap/types.ts#L49) -The upated return for the given swap, either `expectedAmountOut` or `expectedAmountIn` depending on swap kind. +The updated return for the given swap, either `expectedAmountOut` or `expectedAmountIn` depending on swap kind. ___ ### buildCall @@ -347,7 +347,7 @@ addLiquiditySingleToken( | Name | Type | Description | | ------------- | ------------- | ------------ | | input | [AddLiquiditySingleTokenInput](https://github.com/balancer/b-sdk/tree/main/src/entities/addLiquidity/types.ts#L27) | Same input used in the corresponding add liquidity operation | -| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liqudity is being added to | +| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liquidity is being added to | **Returns** @@ -373,7 +373,7 @@ addLiquidityUnbalanced = async ( | Name | Type | Description | | ------------- | ------------- | ------------ | | input | AddLiquidityUnbalancedInput | Same input used in the corresponding add liquidity operation | -| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liqudity is being added to | +| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liquidity is being added to | **Returns** @@ -429,7 +429,7 @@ removeLiquidity = async ( | ------------- | ------------- | ------------ | | input | [RemoveLiquiditySingleTokenExactInInput](https://github.com/balancer/b-sdk/tree/main/src/entities/removeLiquidity/types.ts#L35) | Same input used in the corresponding remove liquidity operation | | input | [RemoveLiquidityUnbalancedInput](https://github.com/balancer/b-sdk/tree/main/src/entities/removeLiquidity/types.ts#L24) | Same input used in the corresponding remove liquidity operation | -| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liqudity is being removed from | +| poolState | [PoolState](https://github.com/balancer/b-sdk/tree/main/src/entities/types.ts#L5) | Current state of pool that liquidity is being removed from | **Returns** diff --git a/docs/integration-guides/guides/add-liquidity-to-pool.md b/docs/integration-guides/guides/add-liquidity-to-pool.md index 62a101cd..b86744a2 100644 --- a/docs/integration-guides/guides/add-liquidity-to-pool.md +++ b/docs/integration-guides/guides/add-liquidity-to-pool.md @@ -185,7 +185,7 @@ Internally, the SDK subtracts 1% from the query output, as shown in `Slippage.ap /** * Applies slippage to an amount in a given direction * - * @param amount amout to apply slippage to + * @param amount amount to apply slippage to * @param direction +1 adds the slippage to the amount, and -1 will remove the slippage from the amount * @returns */ diff --git a/docs/integration-guides/guides/create-custom-router.md b/docs/integration-guides/guides/create-custom-router.md index 3ce208a4..3b7d8456 100644 --- a/docs/integration-guides/guides/create-custom-router.md +++ b/docs/integration-guides/guides/create-custom-router.md @@ -12,8 +12,8 @@ A custom Router is a smart contract which interacts with the Balancer Vault and - DeFi projects looking to provide liquidity on Balancer in custom proportions across multiple pools with more granular control metrics as part of the liquidity provisioning - DeFi projects looking to enhance the liquidity mining experience for LPs by introducing a better staking & migration flow. -The main work custom routers in the outlined examples above have in commin is that: -- They utilize multiple Vault interactions based on the required usecase +The main work custom routers in the outlined examples above have in common is that: +- They utilize multiple Vault interactions based on the required use-case - They add additional control flows & external interactions to the Router smart contract for granular liquidity operations ## Usage @@ -45,7 +45,7 @@ interface IMockLiquidityGauge { * @title MigrationRouter * @notice Router for migrating liquidity from one pool to another and staking the new BPT * @dev This contract utilizes proportional remove liquidity and unbalanced add liquidity to ensure - * accrued credit on withdrawl is perfectly canceled out via debt accrued on the add liquidity operation, ensuring no + * accrued credit on withdrawal is perfectly canceled out via debt accrued on the add liquidity operation, ensuring no * ERC20 Tokens (Except the BPT) need to be transferred. */ contract MigrationRouter { diff --git a/docs/integration-guides/guides/remove-liquidity-from-pool.md b/docs/integration-guides/guides/remove-liquidity-from-pool.md index 9c718878..68c57470 100644 --- a/docs/integration-guides/guides/remove-liquidity-from-pool.md +++ b/docs/integration-guides/guides/remove-liquidity-from-pool.md @@ -195,7 +195,7 @@ Internally, the SDK subtracts 1% from the query output, as shown in `Slippage.ap /** * Applies slippage to an amount in a given direction * - * @param amount amout to apply slippage to + * @param amount amount to apply slippage to * @param direction +1 adds the slippage to the amount, and -1 will remove the slippage from the amount * @returns */ diff --git a/docs/integration-guides/guides/swapping-custom-paths-with-router.md b/docs/integration-guides/guides/swapping-custom-paths-with-router.md index 0c2de425..eb1ce62e 100644 --- a/docs/integration-guides/guides/swapping-custom-paths-with-router.md +++ b/docs/integration-guides/guides/swapping-custom-paths-with-router.md @@ -205,7 +205,7 @@ Internally, the SDK subtracts 1% from the query output, as shown in `Slippage.ap /** * Applies slippage to an amount in a given direction * - * @param amount amout to apply slippage to + * @param amount amount to apply slippage to * @param direction +1 adds the slippage to the amount, and -1 will remove the slippage from the amount * @returns */ @@ -448,7 +448,7 @@ struct SwapPathExactAmountIn { * each `path` defines a `minAmountOut`. If the amount of `tokenOut` is less than this (e.g. because of slippage) the transaction will revert * pool add/remove operations can be included in the path by using a pool address as tokenIn/Out * tokenIn == pool: router will remove liquidity from pool to a single token, `tokenOut` - * tokenOut == pool: router will add liqudity using `tokenIn` + * tokenOut == pool: router will add liquidity using `tokenIn` #### Javascript diff --git a/docs/integration-guides/guides/swaps-for-aggregators.md b/docs/integration-guides/guides/swaps-for-aggregators.md index 2c370247..6b4e821c 100644 --- a/docs/integration-guides/guides/swaps-for-aggregators.md +++ b/docs/integration-guides/guides/swaps-for-aggregators.md @@ -47,7 +47,7 @@ Dynamic Swap Fees and Hooks are still WIP and not finalised * The Vault uses the `_getSwapFeePercentage(PoolConfig memory config)` to fetch the swap fee from the pool. This function can implement arbitrary logic. * Even when a pool is set to use dynamic swap fees, it still maintains a static swap fee. However, this static fee is not utilized. -The psuedo logic to determine how swap fee is calculated looks like: +The pseudo logic to determine how swap fee is calculated looks like: ``` swapFeePercentage = Pool has DynamicSwapFee => call DynamicSwapFeeHook in the pool @@ -69,7 +69,7 @@ Checkout Javascript and Solidity examples [here](./swapping-custom-paths-with-ro ### Multi-path Swaps -Swaps paths constucted of steps through multiple pools/tokens can be made using [swapExactIn](../../developer-reference/contracts/batch-router-api.md#swapexactin) and [swapExactOut](../../developer-reference/contracts/batch-router-api.md#swapexactout) functions. +Swaps paths constructed of steps through multiple pools/tokens can be made using [swapExactIn](../../developer-reference/contracts/batch-router-api.md#swapexactin) and [swapExactOut](../../developer-reference/contracts/batch-router-api.md#swapexactout) functions. A `SwapPathStep` is defined as: ``` @@ -81,7 +81,7 @@ struct SwapPathStep { and paths can include add/remove liquidity steps by using the address of the respective pool. For example, the following `SwapPathExactAmountIn` would execute a swap of USDC to BAL then add liquidity to the 80/20 BAL/WETH pool. ```solidity -// Note - psuedo code +// Note - pseudo code SwapPathExactAmountIn { tokenIn: USDC // for each step: diff --git a/docs/integration-guides/guides/swaps-with-sor-sdk.md b/docs/integration-guides/guides/swaps-with-sor-sdk.md index f4c751a0..b7aca333 100644 --- a/docs/integration-guides/guides/swaps-with-sor-sdk.md +++ b/docs/integration-guides/guides/swaps-with-sor-sdk.md @@ -174,7 +174,7 @@ Internally, the SDK subtracts 1% from the query output, as shown in `Slippage.ap /** * Applies slippage to an amount in a given direction * - * @param amount amout to apply slippage to + * @param amount amount to apply slippage to * @param direction +1 adds the slippage to the amount, and -1 will remove the slippage from the amount * @returns */ diff --git a/docs/partner-onboarding/balancer-v2/onboard-yb-token.md b/docs/partner-onboarding/balancer-v2/onboard-yb-token.md index 54af6a26..3a68ee78 100644 --- a/docs/partner-onboarding/balancer-v2/onboard-yb-token.md +++ b/docs/partner-onboarding/balancer-v2/onboard-yb-token.md @@ -32,7 +32,7 @@ For security reasons and to make sure your rate provider adheres to Balancer’s standards, please initiate a rate provider review [here](https://github.com/balancer/code-review/issues) ::: info -Depending on the complexit of your rate provider, reviews usually take up to 1-2 weeks for Balancer labs to complete. +Depending on the complexity of your rate provider, reviews usually take up to 1-2 weeks for Balancer labs to complete. Consult the [issue board](https://github.com/balancer/code-review/issues) for the review status ::: @@ -82,7 +82,7 @@ For more details, consult our [gauge onboarding guide](./gauge-onboarding.md). T 1. Post a proposal based on the gauge proposal [instruction set](https://forum.balancer.fi/t/instructions-overview/2674/2) -2. Balancer contributors will make sure all criteria are met and post votes by Thurdsays +2. Balancer contributors will make sure all criteria are met and post votes by Thursdays 3. The voting round lasts from Thursday 8PM CET until the following Monday 8PM CET 4. After a successful vote, an on-chain transaction to add gauges to the gauge controller has to be executed. This usually happens until Tuesday evening CET diff --git a/docs/partner-onboarding/balancer-v2/v2-overview.md b/docs/partner-onboarding/balancer-v2/v2-overview.md index f29a4a07..4b991573 100644 --- a/docs/partner-onboarding/balancer-v2/v2-overview.md +++ b/docs/partner-onboarding/balancer-v2/v2-overview.md @@ -5,15 +5,15 @@ order: 0 ## Onboarding to Balancer v2 Balancer v2 has been a core pillar of DeFi since 2021. By leveraging innovative pool types Balancer v2 has attracted -liquidity in the liquid stakig token (LST) and liquid restaking token (LRT) sector. +liquidity in the liquid staking token (LST) and liquid restaking token (LRT) sector. Balancer Technology provides decentralised infrastructure for DAOs, which enables efficient scaling of Yield Bearing assets, creating advanced Governance positions, and developing customised pool types. In addition, the Balancer ecosystem facilitates the streamlined scaling of liquidity for DAOs through core pool incentive flywheels and its network of liquidity enhancing protocols. -### Onboaring Steps +### Onboarding Steps Onboarding to Balancer v2's tech stack involves various steps depending on the specific needs. In general the onboarding journey consists of following steps: 1. Choosing and launching your pool -2. Providing initial liqudity +2. Providing initial liquidity 3. Onboard to Balancer's gauge system 4. Voting Incentive Markets @@ -25,7 +25,7 @@ Balancer v2 offers a wide variety of exciting pool types. The following table pr | Composable Table Pool | Provision of highly correlated asset liquidity | [wstETH:WETH pool](https://app.balancer.fi/#/ethereum/pool/0x93d199263632a4ef4bb438f1feb99e57b4b5f0bd0000000000000000000005c2) on mainnet | | Weighted Pools incl. 80/20 | Creation of pools with any weight distribution with up to 8 tokens. | [BAL:WETH 80:20 pool](https://app.balancer.fi/#/ethereum/pool/0x93d199263632a4ef4bb438f1feb99e57b4b5f0bd0000000000000000000005c2) | | Gyroscope E-CLPs | Specialized pools with [customized liquidity curves](https://docs.gyro.finance/gyroscope-protocol/readme) | [USDC:GYD Stable Pool](https://app.balancer.fi/#/ethereum/pool/0xc2aa60465bffa1a88f5ba471a59ca0435c3ec5c100020000000000000000062c) on mainnet | -| Managed pools | Specialized pools with dynamic pool weights. See [Kassandra Finance](https://app.kassandra.finance/) for an example implemenation use-case | [Example index fund](https://app.kassandra.finance/pool/1370xc22bb237a5b8b7260190cb9e4998a9901a68af6f000100000000000000000d8d) on Avalanche | +| Managed pools | Specialized pools with dynamic pool weights. See [Kassandra Finance](https://app.kassandra.finance/) for an example implementation use-case | [Example index fund](https://app.kassandra.finance/pool/1370xc22bb237a5b8b7260190cb9e4998a9901a68af6f000100000000000000000d8d) on Avalanche | - On Balancer v2, many projects choose to utilize our highly efficient Composable Stable Pool technology. This allows to deploy deep liquidity while guaranteeing correct trades through [rate provider](./rate-providers.md) technology. Furthermore, by harnessing our [vault architecture](../../concepts/vault/README.md) design, pools benefit from direct trading routes, aggregator integration and deep liquidity. - Our flexible weighted pool design allows for innovative pool design, letting you choose between any target weights and up to 8 token pools opening up the possibility to host governance token liquidity or build exciting index-fund like products. diff --git a/docs/partner-onboarding/balancer-v2/voting-markets.md b/docs/partner-onboarding/balancer-v2/voting-markets.md index 452f54a8..1998ad6a 100644 --- a/docs/partner-onboarding/balancer-v2/voting-markets.md +++ b/docs/partner-onboarding/balancer-v2/voting-markets.md @@ -13,7 +13,7 @@ There exist several voting markets to encourage voting for Balancer gauges on Ba Balancer DAO does not endorse any voting market and encourages protocol participants to explore available options independently. ## Voting Markets and the Core Pool Framework -A fraction of core pool revenue is recycled back into voting markets as voting incentives to align BAL token emissions with pool performance. The core pool framework allows participants to benefit from Balancer's success and attract more liquidity through attractive emissions. The configuration of the emission ratio is decidec by Balancer governance and is subject to change. The Balancer DAO currently places voting incentives in USDC on Ethereum mainnet. +A fraction of core pool revenue is recycled back into voting markets as voting incentives to align BAL token emissions with pool performance. The core pool framework allows participants to benefit from Balancer's success and attract more liquidity through attractive emissions. The configuration of the emission ratio is decided by Balancer governance and is subject to change. The Balancer DAO currently places voting incentives in USDC on Ethereum mainnet. ## Voting Market Emission Efficiency and Core Pools A topic that comes up frequently when interacting with voting markets is the analysis of emission efficiency. The emission efficiency is a ratio of the $ value of placed voting incentives vs emissions received for votes placed. Ideally, for an entity placing voting incentives, emission efficiency should stay above 1, so that more token rewards are emitted to a gauge than invested in $ value terms. Note that the voting marketplace landscape is a dynamic system and depends on many factors like overall incentive allocation, token prices and market dynamics. The core pool framework dictates placing of voting incentives independent of emission efficiency as per current [voted in governance](https://forum.balancer.fi/t/bip-19-incentivize-core-pools-l2-usage/3329). Therefore, it is crucial for parties interested in placing voting incentives to understand these implications and act accordingly. diff --git a/docs/partner-onboarding/onboarding-overview/introduction.md b/docs/partner-onboarding/onboarding-overview/introduction.md index b2abc45f..88a30d91 100644 --- a/docs/partner-onboarding/onboarding-overview/introduction.md +++ b/docs/partner-onboarding/onboarding-overview/introduction.md @@ -26,7 +26,7 @@ Balancer Technology provides innovative AMM designs such as 1. **[Boosted Pools](./products/boostedpools.md)**: Leverage token utilization for optimal yield. 2. **[Yield-Bearing liquidity pools](products/lstandlrt.md)**: Optimised LP tech for liquid-staking tokens (LST) and yield-bearing stablecoins. 3. **[ve8020 / Governance Tokenomics](products/ve8020.md)**: Enhanced liquidity dynamics and aligned incentive structures for governance positions. -4. **[Stable Pools](products/stablecoinliquidity.md)**: Advanced technology for highly correlated stableassets, such as Gyro-stable pools. +4. **[Stable Pools](products/stablecoinliquidity.md)**: Advanced technology for highly correlated stable assets, such as Gyro-stable pools. ## High-Level Overview of Onboarding Process diff --git a/docs/partner-onboarding/onboarding-overview/products/lstandlrt.md b/docs/partner-onboarding/onboarding-overview/products/lstandlrt.md index a78753e6..174fafa4 100644 --- a/docs/partner-onboarding/onboarding-overview/products/lstandlrt.md +++ b/docs/partner-onboarding/onboarding-overview/products/lstandlrt.md @@ -11,7 +11,7 @@ counterparts. These tokenised assets allow users to gain exposure to both on-cha 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: 1. [Rate provider](../../balancer-v2/rate-providers.md) technology -2. [Core Pool Dynamcis](../../balancer-v2/core-pools.md) +2. [Core Pool Dynamics](../../balancer-v2/core-pools.md) 3. [Boosted pools](../products/boostedpools.md) #### Rate provider technology diff --git a/docs/partner-onboarding/onboarding-overview/products/ve8020.md b/docs/partner-onboarding/onboarding-overview/products/ve8020.md index fbae3fe2..2235ef27 100644 --- a/docs/partner-onboarding/onboarding-overview/products/ve8020.md +++ b/docs/partner-onboarding/onboarding-overview/products/ve8020.md @@ -4,11 +4,11 @@ title: Governance Tokenomics (ve80/20) --- # Governance Tokenomics :::info -Single Asset staking is an outdated governance tokenomics model that reduces a tokens liquidity, increases token volatility and slippage, Incentivises 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. +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. ::: ## Challenges surrounding Governance Tokenomics -Single Asset staking is an outdated governance tokenomics model that reduces a tokens liquidity, increases token volatility/slippage, Incentivises mercenary capital, and creates fragmented and expensive incentive programs. +Single Asset staking is an outdated governance tokenomics model that reduces a tokens liquidity, increases token volatility/slippage, Incentivizes mercenary capital, and creates fragmented and expensive incentive programs. ## The ve8020 Initiative as a Solution for Governance Tokenomics ve8020 combines the flexibility of asymmetric weighted pools, with the efficiency of vote-escrowed mechanics to unlock the next evolution of Governance tokenomics to unlock deep Liquidity, asymmetric asset exposure with minimised IL, and highly efficient incentive programs. @@ -34,7 +34,7 @@ Harnessing a liquidity pool token as the governance token, the 8020 model circum By addressing the limitations of traditional single-sided staking, the 8020 model fosters an ecosystem where liquidity thrives, enabling smoother and more efficient trading experiences for users. For reference, at the time of writing, Balancer’s 8020 governance pool hosts a TVL of [over $145m](https://app.balancer.fi/#/ethereum/pool/0x5c6ee304399dbdb9c8ef030ab642b10820db8f56000200000000000000000014), leading to BAL being one of the most liquid tokens in DeFi. ## Unlock highly efficient incentive programs -Unlike a single staking model which requires DAOs to direct incentives at other positions to ensure liquidity is averrable for swaps, a ve8020 model ensures a SINGLE, concentrated source for protocols to direct incentives at. Combined with swap fees, core pools, and BAL liquidity flywheels, this unlocks an extremely efficient incentive program for protocols. +Unlike a single staking model which requires DAOs to direct incentives at other positions to ensure liquidity is available for swaps, a ve8020 model ensures a SINGLE, concentrated source for protocols to direct incentives at. Combined with swap fees, core pools, and BAL liquidity flywheels, this unlocks an extremely efficient incentive program for protocols. ### Traditional single staked position inefficiencies for protocol incentive programs With the need to facilitate swaps, the traditional single-sided model necessitates incentives for both the staking pool and other liquidity pools. By integrating the governance token into an 8020 liquidity pool, the need to split and direct incentives to other DEXs/CEXs is eliminated. Incentives can be directed to one place offering users a more enticing position. @@ -70,7 +70,7 @@ Below are a few of our successful 8020 ecosystem participants: - [Aave](https://app.aave.com/) ## Onboarding -ve8020 onboarding requires the creation of a weighted pool with a vote escrowed position on top. Protocols only need to incentivise the locked position to ensure long-term liquidity, with a Balancer grant there is a possibility to boost these incentives further. There are also means to generate liquidity mining incentives LP on Balancer. - Core Pool Designation. +ve8020 onboarding requires the creation of a weighted pool with a vote escrowed position on top. Protocols only need to incentivize the locked position to ensure long-term liquidity, with a Balancer grant there is a possibility to boost these incentives further. There are also means to generate liquidity mining incentives LP on Balancer. - Core Pool Designation. ::: info Follow our Balancer v2 [Onboarding Guide](../../balancer-v2/v2-overview.md) ::: diff --git a/docs/tools/README.md b/docs/tools/README.md index 2d9b0733..10f2f3b3 100644 --- a/docs/tools/README.md +++ b/docs/tools/README.md @@ -8,4 +8,4 @@ --- -These tools have been developed by various teams contributing to the Balancer Ecosystem or wider DeFi through grants, as general contributors or separate platforms entirely. This hub serves as an open source repo of these tools created to help users and devs navigate, analyse and interact with the Balancer Ecosystem. This is continously growing so if you have something you think should be on this page, get in touch and add your project to the [open source repo here](https://github.com/balancer/docs/tree/main/docs/tools) for it to be added! \ No newline at end of file +These tools have been developed by various teams contributing to the Balancer Ecosystem or wider DeFi through grants, as general contributors or separate platforms entirely. This hub serves as an open source repo of these tools created to help users and devs navigate, analyse and interact with the Balancer Ecosystem. This is continuously growing so if you have something you think should be on this page, get in touch and add your project to the [open source repo here](https://github.com/balancer/docs/tree/main/docs/tools) for it to be added! \ No newline at end of file