From 2b1f3048e9bfd90351eed0ab1e7ed2496ac4ad17 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 20:41:39 +0530 Subject: [PATCH 01/10] fix: strategies links --- docs/contracts/liquidity-launchpad/01-introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contracts/liquidity-launchpad/01-introduction.md b/docs/contracts/liquidity-launchpad/01-introduction.md index ed97ad95f..44be59bad 100644 --- a/docs/contracts/liquidity-launchpad/01-introduction.md +++ b/docs/contracts/liquidity-launchpad/01-introduction.md @@ -34,7 +34,7 @@ The Uniswap Liquidity Launchpad framework is built on three coordinated componen 1. **[Liquidity Launcher →](https://github.com/Uniswap/liquidity-launcher)** Central orchestration contract that coordinates distribution and liquidity deployment 2. **[Token Factory →](https://github.com/Uniswap/uerc20-factory)** (Optional) Creates new ERC-20 tokens with metadata, or integrates existing tokens -3. **Liquidity Strategies** - Modular contracts for different price discovery and liquidity mechanisms (prebuilt [LBP Strategy](https://github.com/Uniswap/liquidity-launcher) or [custom strategies](./05-strategies.md#writing-a-custom-strategy)) +3. **Liquidity Strategies** - Modular contracts for different price discovery and liquidity mechanisms (prebuilt [LBP Strategy](./06-strategies.md#lbpstrategybase) or [custom strategies](./06-strategies.md#writing-a-custom-strategy)) Each component is designed to be composable and extensible, allowing you to customize your liquidity bootstrapping while maintaining security and fairness guarantees. From f49845a6a25233670673cab851951b299fd93e31 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 20:42:42 +0530 Subject: [PATCH 02/10] fix: USDC name --- docs/sdk/v3/guides/advanced/02-pool-data.md | 2 +- docs/sdk/v3/guides/swaps/01-quoting.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/sdk/v3/guides/advanced/02-pool-data.md b/docs/sdk/v3/guides/advanced/02-pool-data.md index 645c05505..031cfb759 100644 --- a/docs/sdk/v3/guides/advanced/02-pool-data.md +++ b/docs/sdk/v3/guides/advanced/02-pool-data.md @@ -72,7 +72,7 @@ export const USDC_TOKEN = new Token( '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', 6, 'USDC', - 'USD//C' + 'USDC' ) ``` diff --git a/docs/sdk/v3/guides/swaps/01-quoting.md b/docs/sdk/v3/guides/swaps/01-quoting.md index 42dfdfbcd..8a36ed6b3 100644 --- a/docs/sdk/v3/guides/swaps/01-quoting.md +++ b/docs/sdk/v3/guides/swaps/01-quoting.md @@ -112,7 +112,7 @@ const USDC_TOKEN = new Token( '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', 6, 'USDC', - 'USD//C' + 'USDC' ) ``` From 66f9b98d7dd70d637e636dba6e27a061d6fd8dbe Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:07:01 +0530 Subject: [PATCH 03/10] fix: missing uint8 --- docs/contracts/v4/guides/position-manager.mdx | 68 +++++++++---------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/docs/contracts/v4/guides/position-manager.mdx b/docs/contracts/v4/guides/position-manager.mdx index f277c4e5f..f7f2a9c54 100644 --- a/docs/contracts/v4/guides/position-manager.mdx +++ b/docs/contracts/v4/guides/position-manager.mdx @@ -14,8 +14,8 @@ At its core, the Position Manager works by executing a sequence of commands: ```solidity // Example: Minting a new position requires two commands bytes memory actions = abi.encodePacked( - Actions.MINT_POSITION, // Create the position - Actions.SETTLE_PAIR // Provide the tokens + uint8(Actions.MINT_POSITION), // Create the position + uint8(Actions.SETTLE_PAIR) // Provide the tokens ); ``` @@ -108,17 +108,17 @@ Understanding how operations create and resolve deltas helps in ordering them ef ```solidity // Efficient: Group operations that create deltas, then resolve them together bytes memory actions = abi.encodePacked( - Actions.MINT_POSITION, // First delta: -100 tokens - Actions.INCREASE_LIQUIDITY, // Second delta: -50 tokens - Actions.SETTLE_PAIR // Resolve total: -150 tokens at once + uint8(Actions.MINT_POSITION), // First delta: -100 tokens + uint8(Actions.INCREASE_LIQUIDITY), // Second delta: -50 tokens + uint8(Actions.SETTLE_PAIR) // Resolve total: -150 tokens at once ); // Less efficient: Resolving deltas multiple times bytes memory actions = abi.encodePacked( - Actions.MINT_POSITION, // Delta: -100 tokens - Actions.SETTLE_PAIR, // Resolve: -100 tokens - Actions.INCREASE_LIQUIDITY, // New delta: -50 tokens - Actions.SETTLE_PAIR // Resolve again: -50 tokens + uint8(Actions.MINT_POSITION), // Delta: -100 tokens + uint8(Actions.SETTLE_PAIR), // Resolve: -100 tokens + uint8(Actions.INCREASE_LIQUIDITY), // New delta: -50 tokens + uint8(Actions.SETTLE_PAIR) // Resolve again: -50 tokens ); ``` @@ -190,8 +190,8 @@ Define the sequence of operations needed for minting: // 1. MINT_POSITION - Creates the position and calculates token requirements // 2. SETTLE_PAIR - Provides the tokens needed bytes memory actions = abi.encodePacked( - Actions.MINT_POSITION, - Actions.SETTLE_PAIR + uint8(Actions.MINT_POSITION), + uint8(Actions.SETTLE_PAIR) ); ``` @@ -249,8 +249,8 @@ Unlike minting where we always use SETTLE_PAIR, increasing liquidity has differe ```solidity bytes memory actions = abi.encodePacked( - Actions.INCREASE_LIQUIDITY, - Actions.SETTLE_PAIR + uint8(Actions.INCREASE_LIQUIDITY), + uint8(Actions.SETTLE_PAIR) ); ``` @@ -258,9 +258,9 @@ bytes memory actions = abi.encodePacked( ```solidity bytes memory actions = abi.encodePacked( - Actions.INCREASE_LIQUIDITY, - Actions.CLOSE_CURRENCY, // For token0 - Actions.CLOSE_CURRENCY // For token1 + uint8(Actions.INCREASE_LIQUIDITY), + uint8(Actions.CLOSE_CURRENCY), // For token0 + uint8(Actions.CLOSE_CURRENCY) // For token1 ); ``` @@ -293,14 +293,14 @@ Choose the appropriate delta resolution based on whether we’re using fees: bytes memory actions; if (useFeesAsLiquidity) { actions = abi.encodePacked( - Actions.INCREASE_LIQUIDITY, // Add liquidity - Actions.CLOSE_CURRENCY, // Handle token0 (might need to pay or receive) - Actions.CLOSE_CURRENCY // Handle token1 (might need to pay or receive) + uint8(Actions.INCREASE_LIQUIDITY), // Add liquidity + uint8(Actions.CLOSE_CURRENCY), // Handle token0 (might need to pay or receive) + uint8(Actions.CLOSE_CURRENCY) // Handle token1 (might need to pay or receive) ); } else { actions = abi.encodePacked( - Actions.INCREASE_LIQUIDITY, // Add liquidity - Actions.SETTLE_PAIR // Provide tokens + uint8(Actions.INCREASE_LIQUIDITY), // Add liquidity + uint8(Actions.SETTLE_PAIR) // Provide tokens ); } ``` @@ -366,8 +366,8 @@ When decreasing liquidity, you’ll receive tokens, so it's most common to recei ```solidity bytes memory actions = abi.encodePacked( - Actions.DECREASE_LIQUIDITY, - Actions.TAKE_PAIR + uint8(Actions.DECREASE_LIQUIDITY), + uint8(Actions.TAKE_PAIR) ); ``` @@ -452,8 +452,8 @@ function collectFees( ) external { // Define the sequence of operations bytes memory actions = abi.encodePacked( - Actions.DECREASE_LIQUIDITY, // Remove liquidity - Actions.TAKE_PAIR // Receive both tokens + uint8(Actions.DECREASE_LIQUIDITY), // Remove liquidity + uint8(Actions.TAKE_PAIR) // Receive both tokens ); // Prepare parameters array @@ -529,8 +529,8 @@ function burnPosition( // 1. BURN_POSITION - Removes the position and creates positive deltas // 2. TAKE_PAIR - Sends all tokens to the recipient bytes memory actions = abi.encodePacked( - Actions.BURN_POSITION, - Actions.TAKE_PAIR + uint8(Actions.BURN_POSITION), + uint8(Actions.TAKE_PAIR) ); ``` @@ -607,9 +607,9 @@ function rebalanceLiquidity( ) external { // Group liquidity operations first, then delta resolutions bytes memory actions = abi.encodePacked( - Actions.BURN_POSITION, // Remove old position - Actions.MINT_POSITION, // Create new position - Actions.SETTLE_PAIR // Provide tokens for new position + uint8(Actions.BURN_POSITION), // Remove old position + uint8(Actions.MINT_POSITION), // Create new position + uint8(Actions.SETTLE_PAIR) // Provide tokens for new position ); ``` @@ -686,8 +686,8 @@ When you can’t predict whether you’ll need to pay or receive tokens, CLOSE_C ```solidity // Example scenario: Converting fees to liquidity bytes memory actions = abi.encodePacked( - Actions.INCREASE_LIQUIDITY, - Actions.CLOSE_CURRENCY // Will automatically settle or take based on final delta + uint8(Actions.INCREASE_LIQUIDITY), + uint8(Actions.CLOSE_CURRENCY) // Will automatically settle or take based on final delta ); bytes[] memory params = new bytes[](2); @@ -739,8 +739,8 @@ SWEEP helps recover any excess tokens sent to the PoolManager: ```solidity bytes memory actions = abi.encodePacked( - Actions.YOUR_MAIN_OPERATION, - Actions.SWEEP // Add at the end to collect any excess + uint8(Actions.YOUR_MAIN_OPERATION), + uint8(Actions.SWEEP) // Add at the end to collect any excess ); // Parameters for SWEEP From abb72811f3cfe31163c629e146b35fb709b5a6ba Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:09:20 +0530 Subject: [PATCH 04/10] fix: QUOTER typo --- docs/sdk/v3/guides/swaps/01-quoting.md | 2 +- docs/sdk/v4/guides/swaps/quoting.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/sdk/v3/guides/swaps/01-quoting.md b/docs/sdk/v3/guides/swaps/01-quoting.md index 8a36ed6b3..b471a047c 100644 --- a/docs/sdk/v3/guides/swaps/01-quoting.md +++ b/docs/sdk/v3/guides/swaps/01-quoting.md @@ -184,7 +184,7 @@ We get access to the contract's ABI through the [@uniswap/v3-periphery](https:// import Quoter from '@uniswap/v3-periphery/artifacts/contracts/lens/Quoter.sol/Quoter.json' ``` -We get the QUOTE_CONTRACT_ADDRESS for our chain from [GitHub](https://github.com/Uniswap/v3-periphery/blob/main/deploys.md). +We get the QUOTER_CONTRACT_ADDRESS for our chain from [GitHub](https://github.com/Uniswap/v3-periphery/blob/main/deploys.md). We can now use our Quoter contract to obtain the quote. diff --git a/docs/sdk/v4/guides/swaps/quoting.md b/docs/sdk/v4/guides/swaps/quoting.md index 1cb8628e4..150becf4c 100644 --- a/docs/sdk/v4/guides/swaps/quoting.md +++ b/docs/sdk/v4/guides/swaps/quoting.md @@ -84,7 +84,7 @@ const quoterContract = new ethers.Contract( ) ``` -We get the `QUOTE_CONTRACT_ADDRESS` for our chain from [Uniswap Deployments](https://docs.uniswap.org/contracts/v4/deployments). +We get the `QUOTER_CONTRACT_ADDRESS` for our chain from [Uniswap Deployments](https://docs.uniswap.org/contracts/v4/deployments). We can now use our Quoter contract to obtain the quote. From 760d46f3994834dbacd5d75c4ff973dbc3e57841 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:18:07 +0530 Subject: [PATCH 05/10] fix: ETH USDC ordering --- docs/sdk/v4/guides/advanced/pool-data.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/sdk/v4/guides/advanced/pool-data.md b/docs/sdk/v4/guides/advanced/pool-data.md index 257bf4493..9c38c3fc1 100644 --- a/docs/sdk/v4/guides/advanced/pool-data.md +++ b/docs/sdk/v4/guides/advanced/pool-data.md @@ -40,8 +40,8 @@ export const CurrentConfig: ExampleConfig = { }, ... poolKey: { - currency0: USDC_TOKEN.address, - currency1: ETH_TOKEN.address, + currency0: ETH_TOKEN.address, + currency1: USDC_TOKEN.address, fee: FEE_AMOUNT_LOW, tickSpacing: TICK_SPACING_TEN, hooks: EMPTY_HOOK, @@ -73,7 +73,7 @@ export const USDC_TOKEN = new Token( ## Computing the PoolId out of PoolKey -In this example, we will construct the **USDC - ETH** Pool with **LOW** fees and without hooks. The SDK provides a method to compute the `PoolId` for this pool: +In this example, we will construct the **ETH - USDC** Pool with **LOW** fees and without hooks. The SDK provides a method to compute the `PoolId` for this pool: ```typescript import { Pool } from '@uniswap/v4-sdk'; From cda4e73575ca5af4c8bc101e1657d648ac6afc3a Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:24:12 +0530 Subject: [PATCH 06/10] fix: broken links --- docs/sdk/v4/guides/swaps/multi-hop-swapping.md | 4 ++-- docs/sdk/v4/guides/swaps/single-hop-swapping.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/sdk/v4/guides/swaps/multi-hop-swapping.md b/docs/sdk/v4/guides/swaps/multi-hop-swapping.md index a2285cafd..3c2f356df 100644 --- a/docs/sdk/v4/guides/swaps/multi-hop-swapping.md +++ b/docs/sdk/v4/guides/swaps/multi-hop-swapping.md @@ -153,8 +153,8 @@ const receipt = await tx.wait() console.log('Multi-hop swap completed! Transaction hash:', receipt.transactionHash) ``` -The token approvals for ERC20 token swaps remain the same as the [single-hop swapping guide](./02-single-hop-swapping.md). +The token approvals for ERC20 token swaps remain the same as the [single-hop swapping guide](./single-hop-swapping.md). ## Next Steps -Now that you're familiar with trading, consider checking out our next guides on [pooling liquidity](../liquidity/01-pool-data.md) to Uniswap! +Now that you're familiar with trading, consider checking out our next guides on [pooling liquidity](../advanced/pool-data.md) to Uniswap! diff --git a/docs/sdk/v4/guides/swaps/single-hop-swapping.md b/docs/sdk/v4/guides/swaps/single-hop-swapping.md index 77cee90c6..38665ebc8 100644 --- a/docs/sdk/v4/guides/swaps/single-hop-swapping.md +++ b/docs/sdk/v4/guides/swaps/single-hop-swapping.md @@ -167,4 +167,4 @@ The rest of the swap process remains the same. ## Next Steps -Now that you understand single-hop swaps, you might want to explore [multi-hop swaps](./03-multi-hop-swapping.md) for trading between tokens without direct pools or enough liquidity. +Now that you understand single-hop swaps, you might want to explore [multi-hop swaps](./multi-hop-swapping.md) for trading between tokens without direct pools or enough liquidity. From df772b6a56c40e773cdbdb37ff9fd5a16ad4f6e8 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:40:06 +0530 Subject: [PATCH 07/10] fix: typos --- docs/sdk/v4/guides/advanced/pool-data.md | 16 ++++++++-------- docs/sdk/v4/guides/liquidity/collecting-fees.md | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/sdk/v4/guides/advanced/pool-data.md b/docs/sdk/v4/guides/advanced/pool-data.md index 9c38c3fc1..348898821 100644 --- a/docs/sdk/v4/guides/advanced/pool-data.md +++ b/docs/sdk/v4/guides/advanced/pool-data.md @@ -85,7 +85,7 @@ const poolId = Pool.getPoolId(currency0, currency1, fee, tickSpacing, hooks); ## Referencing the StateView contract and fetching metadata -Now that we have the `PoolId` of a **USDC - ETH** Pool, we need to call [StateView](/contracts/v4/guides/state-view) contract to get the pool state. In v4 you need to use `StateLibrary` to read pool state, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where `StateView` comes in. +Now that we have the `PoolId` of a **ETH - USDC** Pool, we need to call [StateView](/contracts/v4/guides/state-view) contract to get the pool state. In v4 you need to use `StateLibrary` to read pool state, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where `StateView` comes in. To construct the Contract we need to provide the address of the contract, its ABI and a provider connected to an RPC endpoint. ```typescript @@ -103,7 +103,7 @@ const stateViewContract = new ethers.Contract( We get the `STATE_VIEW_ADDRESS` for our chain from [Uniswap Deployments](/contracts/v4/deployments). Once we have set up our reference to the contract, we can proceed to access its methods. To construct our offchain representation of the Pool, we need to fetch its liquidity, sqrtPrice, currently active tick and the full Tick data. -We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `getLiquidity()`and `getSlot0()` on the StateView contract: +We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `getLiquidity()` and `getSlot0()` on the StateView contract: ```typescript const [slot0, liquidity] = await Promise.all([ @@ -127,12 +127,12 @@ For our use case, we only need the `sqrtPriceX96` and the currently active `tick ## Fetching all Ticks v4 pools use ticks to [concentrate liquidity](/concepts/protocol/concentrated-liquidity) in price ranges and allow for better pricing of trades. -Even though most Pools only have a couple of **initialized ticks**, it is possible that a pools liquidity is defined by thousands of **initialized ticks**. +Even though most Pools only have a couple of **initialized ticks**, it is possible that a pool's liquidity is defined by thousands of **initialized ticks**. In that case, it can be very expensive or slow to get all of them with normal RPC calls. If you are not familiar with the concept of ticks, check out the [`introduction`](/concepts/protocol/concentrated-liquidity#ticks). -To access tick data, we will use the `getTickInfo` function of the State View contract: +To access tick data, we will use the `getTickInfo` function of the StateView contract: ```solidity function getTickInfo(PoolId poolId, int24 tick) @@ -148,7 +148,7 @@ To access tick data, we will use the `getTickInfo` function of the State View co The `tick` parameter that we provide the function with is the **index** (memory position) of the Tick we are trying to fetch. To get the indices of all initialized Ticks of the Pool, we can calculate them from the **tickBitmaps**. -To fetch a `tickBitmap` we use a `getTickBitmap` function of the State View contract: +To fetch a `tickBitmap` we use a `getTickBitmap` function of the StateView contract: ```solidity function getTickBitmap( @@ -159,7 +159,7 @@ To fetch a `tickBitmap` we use a `getTickBitmap` function of the State View cont A pool stores lots of bitmaps, each of which contain the status of 256 Ticks. The parameter `int16 wordPosition` the function accepts is the position of the bitMap we want to fetch. -We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependant on the Fee tier. +We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependent on the fee tier. So to summarise we need 4 steps to fetch all initialized ticks: @@ -176,7 +176,7 @@ Multicall contracts **aggregate results** from multiple contract calls and there This can improve the **speed** of fetching large amounts of data significantly and ensures that the data fetched is all from the **same block**. We will use the Multicall2 contract by MakerDAO. -We use the `ethers-muticall` npm package to easily interact with the Contract. +We use the `ethers-multicall` npm package to easily interact with the Contract. ## Calculating all bitMap positions @@ -207,7 +207,7 @@ One word contains 256 ticks, so we can compress the ticks by right shifting 8 bi Knowing the positions of words, we can now fetch them using multicall. -First we initialize our multicall providers and State View Contract: +First we initialize our multicall providers and StateView Contract: ```typescript import { ethers } from 'ethers' diff --git a/docs/sdk/v4/guides/liquidity/collecting-fees.md b/docs/sdk/v4/guides/liquidity/collecting-fees.md index 3892b3c44..0150902b6 100644 --- a/docs/sdk/v4/guides/liquidity/collecting-fees.md +++ b/docs/sdk/v4/guides/liquidity/collecting-fees.md @@ -246,7 +246,7 @@ async function verifyFeeCollection(receipt, userAddress, positionDetails, ethBal ### Check Your Token Balances -You can simply measuring the balance change in your wallet before vs. after the call. For example, read your token balances (and ETH balance) prior to calling, then after the transaction confirm the increases. Because v4 might auto-wrap or unwrap ETH, if one of the tokens was ETH you should check your ETH balance difference. In ETH pools, no ERC-20 transfer event will fire for the ETH – the ETH will be sent directly to you (as an internal transfer), which is why checking the balance or the transaction's internal traces is necessary to confirm the amount. +You can simply measure the balance change in your wallet before vs. after the call. For example, read your token balances (and ETH balance) prior to calling, then after the transaction confirm the increases. Because v4 might auto-wrap or unwrap ETH, if one of the tokens was ETH you should check your ETH balance difference. In ETH pools, no ERC-20 transfer event will fire for the ETH – the ETH will be sent directly to you (as an internal transfer), which is why checking the balance or the transaction's internal traces is necessary to confirm the amount. ```typescript // Check native ETH balance changes From 25a5e9649dc981eb9fa3a7cdae5b1ac70020ba95 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:45:18 +0530 Subject: [PATCH 08/10] Revert "fix: typos" This reverts commit df772b6a56c40e773cdbdb37ff9fd5a16ad4f6e8. --- docs/sdk/v4/guides/advanced/pool-data.md | 16 ++++++++-------- docs/sdk/v4/guides/liquidity/collecting-fees.md | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/sdk/v4/guides/advanced/pool-data.md b/docs/sdk/v4/guides/advanced/pool-data.md index 348898821..9c38c3fc1 100644 --- a/docs/sdk/v4/guides/advanced/pool-data.md +++ b/docs/sdk/v4/guides/advanced/pool-data.md @@ -85,7 +85,7 @@ const poolId = Pool.getPoolId(currency0, currency1, fee, tickSpacing, hooks); ## Referencing the StateView contract and fetching metadata -Now that we have the `PoolId` of a **ETH - USDC** Pool, we need to call [StateView](/contracts/v4/guides/state-view) contract to get the pool state. In v4 you need to use `StateLibrary` to read pool state, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where `StateView` comes in. +Now that we have the `PoolId` of a **USDC - ETH** Pool, we need to call [StateView](/contracts/v4/guides/state-view) contract to get the pool state. In v4 you need to use `StateLibrary` to read pool state, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where `StateView` comes in. To construct the Contract we need to provide the address of the contract, its ABI and a provider connected to an RPC endpoint. ```typescript @@ -103,7 +103,7 @@ const stateViewContract = new ethers.Contract( We get the `STATE_VIEW_ADDRESS` for our chain from [Uniswap Deployments](/contracts/v4/deployments). Once we have set up our reference to the contract, we can proceed to access its methods. To construct our offchain representation of the Pool, we need to fetch its liquidity, sqrtPrice, currently active tick and the full Tick data. -We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `getLiquidity()` and `getSlot0()` on the StateView contract: +We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `getLiquidity()`and `getSlot0()` on the StateView contract: ```typescript const [slot0, liquidity] = await Promise.all([ @@ -127,12 +127,12 @@ For our use case, we only need the `sqrtPriceX96` and the currently active `tick ## Fetching all Ticks v4 pools use ticks to [concentrate liquidity](/concepts/protocol/concentrated-liquidity) in price ranges and allow for better pricing of trades. -Even though most Pools only have a couple of **initialized ticks**, it is possible that a pool's liquidity is defined by thousands of **initialized ticks**. +Even though most Pools only have a couple of **initialized ticks**, it is possible that a pools liquidity is defined by thousands of **initialized ticks**. In that case, it can be very expensive or slow to get all of them with normal RPC calls. If you are not familiar with the concept of ticks, check out the [`introduction`](/concepts/protocol/concentrated-liquidity#ticks). -To access tick data, we will use the `getTickInfo` function of the StateView contract: +To access tick data, we will use the `getTickInfo` function of the State View contract: ```solidity function getTickInfo(PoolId poolId, int24 tick) @@ -148,7 +148,7 @@ To access tick data, we will use the `getTickInfo` function of the StateView con The `tick` parameter that we provide the function with is the **index** (memory position) of the Tick we are trying to fetch. To get the indices of all initialized Ticks of the Pool, we can calculate them from the **tickBitmaps**. -To fetch a `tickBitmap` we use a `getTickBitmap` function of the StateView contract: +To fetch a `tickBitmap` we use a `getTickBitmap` function of the State View contract: ```solidity function getTickBitmap( @@ -159,7 +159,7 @@ To fetch a `tickBitmap` we use a `getTickBitmap` function of the StateView contr A pool stores lots of bitmaps, each of which contain the status of 256 Ticks. The parameter `int16 wordPosition` the function accepts is the position of the bitMap we want to fetch. -We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependent on the fee tier. +We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependant on the Fee tier. So to summarise we need 4 steps to fetch all initialized ticks: @@ -176,7 +176,7 @@ Multicall contracts **aggregate results** from multiple contract calls and there This can improve the **speed** of fetching large amounts of data significantly and ensures that the data fetched is all from the **same block**. We will use the Multicall2 contract by MakerDAO. -We use the `ethers-multicall` npm package to easily interact with the Contract. +We use the `ethers-muticall` npm package to easily interact with the Contract. ## Calculating all bitMap positions @@ -207,7 +207,7 @@ One word contains 256 ticks, so we can compress the ticks by right shifting 8 bi Knowing the positions of words, we can now fetch them using multicall. -First we initialize our multicall providers and StateView Contract: +First we initialize our multicall providers and State View Contract: ```typescript import { ethers } from 'ethers' diff --git a/docs/sdk/v4/guides/liquidity/collecting-fees.md b/docs/sdk/v4/guides/liquidity/collecting-fees.md index 0150902b6..3892b3c44 100644 --- a/docs/sdk/v4/guides/liquidity/collecting-fees.md +++ b/docs/sdk/v4/guides/liquidity/collecting-fees.md @@ -246,7 +246,7 @@ async function verifyFeeCollection(receipt, userAddress, positionDetails, ethBal ### Check Your Token Balances -You can simply measure the balance change in your wallet before vs. after the call. For example, read your token balances (and ETH balance) prior to calling, then after the transaction confirm the increases. Because v4 might auto-wrap or unwrap ETH, if one of the tokens was ETH you should check your ETH balance difference. In ETH pools, no ERC-20 transfer event will fire for the ETH – the ETH will be sent directly to you (as an internal transfer), which is why checking the balance or the transaction's internal traces is necessary to confirm the amount. +You can simply measuring the balance change in your wallet before vs. after the call. For example, read your token balances (and ETH balance) prior to calling, then after the transaction confirm the increases. Because v4 might auto-wrap or unwrap ETH, if one of the tokens was ETH you should check your ETH balance difference. In ETH pools, no ERC-20 transfer event will fire for the ETH – the ETH will be sent directly to you (as an internal transfer), which is why checking the balance or the transaction's internal traces is necessary to confirm the amount. ```typescript // Check native ETH balance changes From b06f40ebcba331c5b40aa6f2c85a89f72ca58100 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:48:33 +0530 Subject: [PATCH 09/10] fix: typos --- docs/sdk/v4/guides/liquidity/collecting-fees.md | 2 +- docs/sdk/v4/guides/swaps/quoting.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/sdk/v4/guides/liquidity/collecting-fees.md b/docs/sdk/v4/guides/liquidity/collecting-fees.md index 3892b3c44..0150902b6 100644 --- a/docs/sdk/v4/guides/liquidity/collecting-fees.md +++ b/docs/sdk/v4/guides/liquidity/collecting-fees.md @@ -246,7 +246,7 @@ async function verifyFeeCollection(receipt, userAddress, positionDetails, ethBal ### Check Your Token Balances -You can simply measuring the balance change in your wallet before vs. after the call. For example, read your token balances (and ETH balance) prior to calling, then after the transaction confirm the increases. Because v4 might auto-wrap or unwrap ETH, if one of the tokens was ETH you should check your ETH balance difference. In ETH pools, no ERC-20 transfer event will fire for the ETH – the ETH will be sent directly to you (as an internal transfer), which is why checking the balance or the transaction's internal traces is necessary to confirm the amount. +You can simply measure the balance change in your wallet before vs. after the call. For example, read your token balances (and ETH balance) prior to calling, then after the transaction confirm the increases. Because v4 might auto-wrap or unwrap ETH, if one of the tokens was ETH you should check your ETH balance difference. In ETH pools, no ERC-20 transfer event will fire for the ETH – the ETH will be sent directly to you (as an internal transfer), which is why checking the balance or the transaction's internal traces is necessary to confirm the amount. ```typescript // Check native ETH balance changes diff --git a/docs/sdk/v4/guides/swaps/quoting.md b/docs/sdk/v4/guides/swaps/quoting.md index 150becf4c..1cef074e7 100644 --- a/docs/sdk/v4/guides/swaps/quoting.md +++ b/docs/sdk/v4/guides/swaps/quoting.md @@ -109,7 +109,7 @@ The result of the call is the number of output tokens you would receive for the It should be noted that `quoteExactInputSingle` is only 1 of 4 different methods that the quoter offers: 1. `quoteExactInputSingle` - given an input amount, produce a quote of the output amount for a swap on a single pool -2. `quoteExactInput` - given an input amount, produce a quote for the output amount a swap over multiple pools +2. `quoteExactInput` - given an input amount, produce a quote for the output amount for a swap over multiple pools 3. `quoteExactOutputSingle` - given a desired output amount, produce a quote for the input amount on a swap over a single pool 4. `quoteExactOutput` - given a desired output amount, produce a quote for the input amount in for a swap over multiple pools From 791956f95f284bd890f7ff1ea430088de5ee9178 Mon Sep 17 00:00:00 2001 From: Dayitva Goel Date: Sat, 28 Feb 2026 21:50:40 +0530 Subject: [PATCH 10/10] fix: pool-data.md issues --- docs/sdk/v4/guides/advanced/pool-data.md | 26 ++++++++++++------------ 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/sdk/v4/guides/advanced/pool-data.md b/docs/sdk/v4/guides/advanced/pool-data.md index 9c38c3fc1..d8e513941 100644 --- a/docs/sdk/v4/guides/advanced/pool-data.md +++ b/docs/sdk/v4/guides/advanced/pool-data.md @@ -85,7 +85,7 @@ const poolId = Pool.getPoolId(currency0, currency1, fee, tickSpacing, hooks); ## Referencing the StateView contract and fetching metadata -Now that we have the `PoolId` of a **USDC - ETH** Pool, we need to call [StateView](/contracts/v4/guides/state-view) contract to get the pool state. In v4 you need to use `StateLibrary` to read pool state, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where `StateView` comes in. +Now that we have the `PoolId` of a **ETH - USDC** Pool, we need to call [StateView](/contracts/v4/guides/state-view) contract to get the pool state. In v4 you need to use `StateLibrary` to read pool state, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where `StateView` comes in. To construct the Contract we need to provide the address of the contract, its ABI and a provider connected to an RPC endpoint. ```typescript @@ -103,7 +103,7 @@ const stateViewContract = new ethers.Contract( We get the `STATE_VIEW_ADDRESS` for our chain from [Uniswap Deployments](/contracts/v4/deployments). Once we have set up our reference to the contract, we can proceed to access its methods. To construct our offchain representation of the Pool, we need to fetch its liquidity, sqrtPrice, currently active tick and the full Tick data. -We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `getLiquidity()`and `getSlot0()` on the StateView contract: +We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `getLiquidity()` and `getSlot0()` on the StateView contract: ```typescript const [slot0, liquidity] = await Promise.all([ @@ -127,12 +127,12 @@ For our use case, we only need the `sqrtPriceX96` and the currently active `tick ## Fetching all Ticks v4 pools use ticks to [concentrate liquidity](/concepts/protocol/concentrated-liquidity) in price ranges and allow for better pricing of trades. -Even though most Pools only have a couple of **initialized ticks**, it is possible that a pools liquidity is defined by thousands of **initialized ticks**. +Even though most Pools only have a couple of **initialized ticks**, it is possible that a pool's liquidity is defined by thousands of **initialized ticks**. In that case, it can be very expensive or slow to get all of them with normal RPC calls. If you are not familiar with the concept of ticks, check out the [`introduction`](/concepts/protocol/concentrated-liquidity#ticks). -To access tick data, we will use the `getTickInfo` function of the State View contract: +To access tick data, we will use the `getTickInfo` function of the StateView contract: ```solidity function getTickInfo(PoolId poolId, int24 tick) @@ -148,7 +148,7 @@ To access tick data, we will use the `getTickInfo` function of the State View co The `tick` parameter that we provide the function with is the **index** (memory position) of the Tick we are trying to fetch. To get the indices of all initialized Ticks of the Pool, we can calculate them from the **tickBitmaps**. -To fetch a `tickBitmap` we use a `getTickBitmap` function of the State View contract: +To fetch a `tickBitmap` we use a `getTickBitmap` function of the StateView contract: ```solidity function getTickBitmap( @@ -159,7 +159,7 @@ To fetch a `tickBitmap` we use a `getTickBitmap` function of the State View cont A pool stores lots of bitmaps, each of which contain the status of 256 Ticks. The parameter `int16 wordPosition` the function accepts is the position of the bitMap we want to fetch. -We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependant on the Fee tier. +We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependent on the Fee tier. So to summarise we need 4 steps to fetch all initialized ticks: @@ -176,7 +176,7 @@ Multicall contracts **aggregate results** from multiple contract calls and there This can improve the **speed** of fetching large amounts of data significantly and ensures that the data fetched is all from the **same block**. We will use the Multicall2 contract by MakerDAO. -We use the `ethers-muticall` npm package to easily interact with the Contract. +We use the `ethers-multicall` npm package to easily interact with the Contract. ## Calculating all bitMap positions @@ -207,7 +207,7 @@ One word contains 256 ticks, so we can compress the ticks by right shifting 8 bi Knowing the positions of words, we can now fetch them using multicall. -First we initialize our multicall providers and State View Contract: +First we initialize our multicall providers and StateView Contract: ```typescript import { ethers } from 'ethers' @@ -245,7 +245,7 @@ const results: bigint[] = (await multicallProvider.all(calls)).map( ) ``` -A great visualization of what the bitMaps look like can be found in the [Uniswap v3 development book](https://uniswapv3book.com/docs/milestone_2/tick-bitmap-index/](https://uniswapv3book.com/milestone_2/tick-bitmap-index.html): +A great visualization of what the bitMaps look like can be found in the [Uniswap v3 development book](https://uniswapv3book.com/milestone_2/tick-bitmap-index.html): TickBitmap @@ -262,7 +262,7 @@ const bit = 1n const initialized = (bitmap & (bit << BigInt(i))) !== 0n ``` -If the tick is **initialized**, we revert the compression from tick to word we made earlier by multiplying the word index with 256, which is the same as left shifting by 8 bit, adding the position we are currently at, and multiplying with the tickSpacing: +If the tick is **initialized**, we revert the compression from tick to word we made earlier by multiplying the word index with 256, which is the same as left shifting by 8 bits, adding the position we are currently at, and multiplying with the tickSpacing: ```typescript const tickIndex = (ind * 256 + i) * tickSpacing @@ -333,9 +333,9 @@ We need to parse the response from our RPC provider to JSBI values that the v4-s We have everything to construct our `Pool` now: ```typescript -const usdcWethPool = new Pool( - USDC, - WETH, +const usdcEthPool = new Pool( + USDC_TOKEN, + ETH_TOKEN, feeAmount, slot0.sqrtPriceX96, liquidity,