Merge pull request #120 from balancer/fix-typos

Fix typos

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.
 

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
 

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/).
 

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.
 
 <!-- prettier-ignore-start -->
 #### COMP WETH 80/20

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

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)

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.
 :::
 
 $$

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.
 

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 [email protected]
@@ -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

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 | ExactOutQueryOutput>
 [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**
 

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
  */

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 {

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
  */

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