Uniswap v4 slippage & price impact, and why the v3 formula breaks and how to get real data via API

01 · The breakWhy v3 slippage math stops working on v4

For years, estimating slippage on Uniswap was a solved problem. A pair like WETH/USDC mapped to a single pool contract (v2) or a handful of fee-tier pools (v3). You pulled the reserves or the tick liquidity for that contract address, applied the constant-product or concentrated-liquidity formula, and out came a price-impact curve. Every aggregator, bot, and analytics dashboard leaned on that one-to-one relationship: one pair → one contract → one curve.

Uniswap v4 dissolved that relationship. There is no longer a pool contract to point at, and "the WETH/USDC pool" is no longer a single thing. If your slippage logic still assumes it is, it now returns a blended number that doesn't describe any market you can actually trade against.

02 · The causeSingleton + hooks: one contract, many pools

Two design changes in v4 are responsible.

The singleton. In v2 and v3, each pool was its own deployed contract. In v4, almost all pool state lives inside one PoolManager contract at 0x000000000004444c5dc75cB358380D2e3dE08A90 on Ethereum mainnet. The protocol does not deploy a contract per pair. Instead, each logical pool is a row of state keyed by a deterministic identifier: the PoolId.

Hooks. PoolId is derived from the pool's static configuration: the two currencies, the fee tier, the tick spacing, and crucially the hooks contract. Hooks are v4's extension point: custom code invoked around swaps and liquidity changes that can apply dynamic fees or otherwise alter execution. Two pools with the same two tokens and the same fee still produce different PoolIds and separate liquidity curves if their hooks differ.

03 · The distinction

Price impact vs slippage: what you're actually measuring

These two terms get used interchangeably and shouldn't be:

• Price impact is the price movement your own trade causes against the pool's liquidity. A $100k swap into a thin pool moves the price more than the same swap into a deep one. It's a deterministic function of trade size and pool depth.
• Slippage is the gap between the price you expected when you submitted and the price you got at execution. It includes price impact plus anything that changed between quote and fill.

On v4, both depend on reading the right pool. A dynamic-fee hook can change the effective cost of the same swap from one block to the next, so a static formula over merged liquidity mis-estimates both numbers. You want the depth and price table of one PoolId, refreshed as the pool changes.

04 · The fix

Reading real per-pool slippage with DEXPoolSlippages

Bitquery indexes DEX pool state into a DEXPools cube, exposed through two schema entries: DEXPoolEvents (swaps, mints, burns) and DEXPoolSlippages (slippage and price-impact tables). The slippage stream simulates swaps through the pool's initialized ticks and returns, per pool:

• MaxAmountIn is the largest amount you can swap in at a given tolerance
• MinAmountOut is the guaranteed minimum output at that level
• Price is the average execution price for that trade size
• SlippageBasisPoints is the tolerance the row is computed for
• both swap directions, AtoB and BtoA

Every row carries Pool.PoolId, so you isolate one v4 market instead of blending all of them. Run this query in the Bitquery IDE.

query LatestSlippageForOneV4Pool {
  EVM(network: eth) {
    DEXPoolSlippages(
      where: {
        Price: {
          Pool: {
            PoolId: {
              is: "0xdce6394339af00981949f5f3baf27e3610c76326a700af57e4b3e3ae4977f78d"
            }
          }
          Dex: { ProtocolName: { is: "uniswap_v4" } }
        }
      }
      orderBy: { descending: Block_Time }
      limit: { count: 10 }
    ) {
      Price {
        AtoB {
          Price
          MinAmountOut
          MaxAmountIn
        }
        BtoA {
          Price
          MinAmountOut
          MaxAmountIn
        }
        Pool {
          PoolId
          CurrencyA {
            Symbol
            SmartContract
          }
          CurrencyB {
            Symbol
            SmartContract
          }
        }
        Dex {
          ProtocolName
          ProtocolVersion
        }
        SlippageBasisPoints
      }
      Block {
        Time
        Number
      }
    }
  }
}

Swap the PoolId for the market you route through and you get its real price-impact table, not an average of every ETH/USDC configuration sharing the manager address.

05 · In practice

Slippage scales with trade size. Read the whole curve.

The reason per-pool accuracy matters: each slippage tolerance maps to a different maximum trade size, and price impact is non-linear. Pulling DEXPoolSlippages for this exact ETH/USDC v4 pool at block 25,350,531 (mid price ≈ 1,694 USDC/ETH) gives the real ladder for selling ETH into USDC:

06 · LiveStream slippage as the pool changes

Because hooks and liquidity events move the curve, a static snapshot ages fast. The same cube streams in real time. Subscribe once and every swap or ModifyLiquidity event refreshes the slippage table across all Uniswap v4 pools. Open this subscription in the Bitquery IDE.

subscription RealtimeSlippage {
  EVM(network: eth) {
    DEXPoolSlippages(
      where: { Price: { Dex: { ProtocolName: { is: "uniswap_v4" } } } }
    ) {
      Price {
        AtoB {
          Price
          MinAmountOut
          MaxAmountIn
        }
        BtoA {
          Price
          MinAmountOut
          MaxAmountIn
        }
        Pool {
          PoolId
          SmartContract
        }
        Dex {
          ProtocolName
          ProtocolFamily
          ProtocolVersion
        }
        SlippageBasisPoints
      }
      Block {
        Time
        Number
      }
    }
  }
}

The same data is available over Kafka streams for high-throughput pipelines, and across EVM chains. Change network to base, bsc, arbitrum, matic, and the rest.

07 · Read backwardThe full picture, end to end

08 · Who needs this

Where accurate v4 slippage actually pays off

09 · Start hereDocs & queries