Swap Mechanics in Uniswap v4 Core

The main component of Uniswap v4 is swap; it manages precise input/output swaps, optimizes gas through flash accounting, and moves price through liquidity ticks. Three main points:

• Each swap moves through initialized liquidity ranges, crossing ticks when it is depleted. The price fluctuates tick by tick.
• Multihop efficiency: By avoiding middlemen, flash accounting settles net balances just once.
• Dynamic fee support: Hooks have the ability to modify fees in real time according to market conditions.

Compared to their predecessors, v4 swaps are therefore both gas-optimized and capital-efficient. lets discuss further about swap and Flash Accounting & Locking.

How swap works on Uniswap v4?

1. User uses a periphery contract (SwapRouter, for example) to initiate a swap
2. Periphery contract unlocks the PoolManager, triggering the manager to call unlockCallback on the periphery
3. Inside the callback function, the periphery executes swap on the manager
4. The manager makes sure the pool is valid and has been initialized
5. The manager checks the hook address attached to the pool (if one does) and checks if it needs to run beforeSwap
6. If yes, beforeSwap is called on the hook contract. If no, skip to next step.
7. After beforeSwap is run, the actual swap is conducted inside the manager contract
8. The manager then charges protocol fees, if any, and emits the Swap event.
9. It again checks the hook address to see if afterSwap needs to run
10. If yes, call afterSwap, else skip to next step
11. Finally, the manager has an overall delta change of balances from the swap. This delta represents which token (and how much) is owed to the user, and which token (and how much) is owed to the manager
12. This BalanceDelta is returned to the periphery contract, which actually settles those balances
13. Finally, the periphery contract is done with the callback - which makes us re-enter the execution context of the unlock function from the manager
14. Manager ensures no balances remain unsettled, locks itself again, and the transaction completes

A key part here is the settlement of balances. How does this work? What exactly is BalanceDelta?

The BalanceDelta value is simply two int values (NOTE: int not uint - it can have a negative value) representing amount0 and amount1 i.e. the amounts of the two tokens relevant to the swap and how much their balance has changed.
 

These values are represented from the perspective of the user. A positive value implies a positive balance change for the user i.e. the PoolManager owes money to the user, and a negative value implies a negative balance change for the user i.e. the user owes money to the PoolManager.

These balances can be settled in one of two ways:

1. Actually transferring tokens in both directions
2. Minting/burning ERC-6909 tokens the user has from previously locked up money in the PoolManager

Therefore - no tokens actually are transferred until the very end of the transaction flow, right before the callback finishes executing. This allows multi-hop swaps to only require token transfers (or 6909 minting/burning) for the initial input and final output tokens without needing to worry about the "in-between" steps since those deltas just get zero'd out.
 

Core Math Behind Swaps

Δx and Δy Formulas:

$$ \Delta x = \Delta \left( \frac{1}{\sqrt{P}} \right) \cdot L $$

$$ \Delta y = \Delta \left( \sqrt{P} \right) \cdot L $$
 

Expanded with Prices:

$$ \Delta x = \left( \frac{1}{\sqrt{P_c}} - \frac{1}{\sqrt{P_b}} \right) \cdot L $$

$$ \Delta y = \left( \sqrt{P_c} - \sqrt{P_a} \right) \cdot L $$
 

Solving for L (Δx Version):

$$ L = \Delta x \cdot \left( \frac{\sqrt{P_b} \sqrt{P_c}}{\sqrt{P_b} - \sqrt{P_c}} \right) $$
 

Solving for L (Δy Version):

$$ L = \frac{\Delta y}{\sqrt{P_c} - \sqrt{P_a}} $$
 

Code Execution Flow

A USDC holder initiates a swap by calling the swap function in the PoolManager contract.

Internally, this function delegates the operation to the swap function in the Pool.sol contract to execute the actual token exchange and settlement.

1. Initial State Variables:
   • Slot0 slot0Start = self.slot0;: This line reads the current slot0 state, which typically holds the most critical state variables of the pool (like sqrtPriceX96, tick, fee settings, etc.).
   • bool zeroForOne = params.zeroForOne;: This boolean indicates the direction of the swap. If true, it means the swap is from token0 to token1; if false, it's from token1 to token0.
      
2. Protocol Fee Calculation:
   • uint256 protocolFee = zeroForOne ? slot0Start.protocolFee().getZeroForOneFee() : slot0Start.protocolFee().getOneForZeroFee();
     • Depending on the swap direction, it’s fetch the accumulated protocol fee for either the token0 or token1 side. Protocol fees are set aside for the protocol (as opposed to liquidity providers).
        
3. Amount Tracking:
   • int256 amountSpecifiedRemaining = params.amountSpecified;: This is the total amount the user wants to swap. It's initially set to the input amount and will decrease as the swap progresses.
   • int256 amountCalculated = 0;: This will accumulate the output amount (or input amount, depending on the exact swap) during the swap.
      
4. Initializing Swap State:
   • result.sqrtPriceX96 = slot0Start.sqrtPriceX96();: The starting square root price (from slot0).
   • result.tick = slot0Start.tick();: The current tick (from slot0).
   • result.liquidity = self.liquidity;: The current liquidity in the pool.
      
5. Fee Configuration:
   • The code checks if there's a fee override provided in the parameters (via a hook). If so, it uses that; otherwise, it uses the fee from slot0.
   • params↑.lpFeeOverride.isOverride(): Checks if the hook provided a fee override.
   • params.lpFeeOverride.removeOverrideFlagAndValidate(): If there's an override, it removes the flag and validates the fee value.
   • Then, the swap fee is calculated as:
     • If there's no protocol fee (i.e., protocolFee == 0), then the swap fee is just the LP fee (lpFee).
     • Otherwise, it combines the protocol fee and the LP fee. The function calculateSwapFee (presumably) adds the protocol fee on top of the LP fee. Note: the exact method of combination is not shown, but typically the total fee would be the sum of the two or a similar structure.
        

Dynamic Fee System

• Hook-Driven Fee Overrides:

  COPY

  1uint24 lpFee = params↑.lpFeeOverride.isOverride()
  2    ? params↑.lpFeeOverride.removeOverrideFlagAndValidate()
  3    : slot0Start.lpFee();

  • Hooks can override default LP fees using lpFeeOverride
  • removeOverrideFlagAndValidate() ensures hook-provided fees are within valid ranges
  • Falls back to pool's default lpFee from Slot0 if no override exists
     

• Swap Fee Calculation:

  COPY

  1swapFee = protocolFee == 0
  2    ? lpFee
  3    : uint16(protocolFee).calculateSwapFee(lpFee);

  • Combines protocol fee (directional) and LP fee into final swap fee
  • Protocol fee takes precedence when non-zero

  • calculateSwapFee() likely computes:

    swapFee = lpFee + (protocolFee * (1 - lpFee))

    (prevents exceeding 100% total fee)
     

  Swap Validation Safeguard

  COPY

  1if (swapFee >= SwapMath.MAX_SWAP_FEE) {
  2    if (params.amountSpecified > 0) {
  3        InvalidFeeForExactOut.selector.revertWith();
  4    }
  5}

  • Critical Protection:
    • Reverts exact-output swaps (amountSpecified > 0) if total fees ≥ 100%
    • Prevents impossible swaps where fees would consume all input tokens
    • Allows exact-input swaps (negative amountSpecified) even with 100% fees (output=0 is valid)
       
  • Fee Units:
    • All fees measured in pips (1 pip = 0.0001%, 1% = 10,000 pips)
    • MAX_SWAP_FEE = 1,000,000 pips (100%)
       

  Key Uniswap v4 Innovations

  • Hook Flexibility:
    • Protocols/DEXs can implement dynamic fee strategies
    • Enables time-based fees, volatility-adjusted fees, whitelist discounts
       
  • Fee Granularity:
    • Directional fees (zeroForOne/oneForZero)
    • Protocol/LP fee separation
       
  • Security First:
    • Explicit validation of edge cases
    • Protection against economic impossibilities
    • Type-safe fee handling (validation at override)
       

  Swap Execution Flow

  1. Check hook for custom fee override
  2. Calculate final swap fee (LP + protocol fees)
  3. Validate fee compatibility with swap type
  4. Proceed with swap mathematics (not shown)
  5. (Post-swap hooks would execute after this logic)

1. Direction-Specific Checks:
   • zeroForOne (swapping token0 → token1):
     • Price must decrease (current price > limit price)
     • Revert if:
       • limit ≥ current_price (PriceLimitAlreadyExceeded)
       • limit ≤ MIN_SQRT_PRICE (PriceLimitOutOfBounds)
   • !zeroForOne (swapping token1 → token0):
     • Price must increase (current price < limit price)
     • Revert if:
       • limit ≤ current_price (PriceLimitAlreadyExceeded)
       • limit ≥ MAX_SQRT_PRICE (PriceLimitOutOfBounds)
          
2. Critical Boundary Conditions:
   • MIN_SQRT_PRICE ≈ 887,272.42 (tick -887272)
   • MAX_SQRT_PRICE ≈ 887,272.42 (tick 887272)
   • Swaps never execute at absolute min/max ticks due to precision limits

• Slippage Protection: Enforces user-specified price boundaries
• Directional Logic: Different rules for token0→token1 vs token1→token0 swaps
• Edge Case Handling:
  • Prevents swaps beyond mathematically supported price ranges
  • Blocks meaningless swaps where limit price is already passed
  • Special initialization exception for MIN_TICK mentioned in comments
• Gas Efficiency: Early reverts before expensive swap calculations

1 // continue swapping as long as we haven't used the entire input/output and haven't reached the price limit
2        while (!(amountSpecifiedRemaining == 0 || result.sqrtPriceX96 == params.sqrtPriceLimitX96)) {
3            step.sqrtPriceStartX96 = result.sqrtPriceX96;
4
5            (step.tickNext, step.initialized) =
6                self.tickBitmap.nextInitializedTickWithinOneWord(result.tick, params.tickSpacing, zeroForOne);
7
8            // ensure that we do not overshoot the min/max tick, as the tick bitmap is not aware of these bounds
9            if (step.tickNext <= TickMath.MIN_TICK) {
10                step.tickNext = TickMath.MIN_TICK;
11            }
12            if (step.tickNext >= TickMath.MAX_TICK) {
13                step.tickNext = TickMath.MAX_TICK;
14            }
15
16            // get the price for the next tick
17            step.sqrtPriceNextX96 = TickMath.getSqrtPriceAtTick(step.tickNext);
18
19            // compute values to swap to the target tick, price limit, or point where input/output amount is exhausted
20            (result.sqrtPriceX96, step.amountIn, step.amountOut, step.feeAmount) = SwapMath.computeSwapStep(
21                result.sqrtPriceX96,
22                SwapMath.getSqrtPriceTarget(zeroForOne, step.sqrtPriceNextX96, params.sqrtPriceLimitX96),
23                result.liquidity,
24                amountSpecifiedRemaining,
25                swapFee
26            );
27
28            // if exactOutput
29            if (params.amountSpecified > 0) {
30                unchecked {
31                    amountSpecifiedRemaining -= step.amountOut.toInt256();
32                }
33                amountCalculated -= (step.amountIn + step.feeAmount).toInt256();
34            } else {
35                // safe because we test that amountSpecified > amountIn + feeAmount in SwapMath
36                unchecked {
37                    amountSpecifiedRemaining += (step.amountIn + step.feeAmount).toInt256();
38                }
39                amountCalculated += step.amountOut.toInt256();
40            }
41
42            // if the protocol fee is on, calculate how much is owed, decrement feeAmount, and increment protocolFee
43            if (protocolFee > 0) {
44                unchecked {
45                    // step.amountIn does not include the swap fee, as it's already been taken from it,
46                    // so add it back to get the total amountIn and use that to calculate the amount of fees owed to the protocol
47                    // cannot overflow due to limits on the size of protocolFee and params.amountSpecified
48                    // this rounds down to favor LPs over the protocol
49                    uint256 delta = (swapFee == protocolFee)
50                        ? step.feeAmount // lp fee is 0, so the entire fee is owed to the protocol instead
51                        : (step.amountIn + step.feeAmount) * protocolFee / ProtocolFeeLibrary.PIPS_DENOMINATOR;
52                    // subtract it from the total fee and add it to the protocol fee
53                    step.feeAmount -= delta;
54                    amountToProtocol += delta;
55                }
56            }
57
58            // update global fee tracker
59            if (result.liquidity > 0) {
60                unchecked {
61                    // FullMath.mulDiv isn't needed as the numerator can't overflow uint256 since tokens have a max supply of type(uint128).max
62                    step.feeGrowthGlobalX128 +=
63                        UnsafeMath.simpleMulDiv(step.feeAmount, FixedPoint128.Q128, result.liquidity);
64                }
65            }
66
67            // Shift tick if we reached the next price, and preemptively decrement for zeroForOne swaps to tickNext - 1.
68            // If the swap doesn't continue (if amountRemaining == 0 or sqrtPriceLimit is met), slot0.tick will be 1 less
69            // than getTickAtSqrtPrice(slot0.sqrtPrice). This doesn't affect swaps, but donation calls should verify both
70            // price and tick to reward the correct LPs.
71            if (result.sqrtPriceX96 == step.sqrtPriceNextX96) {
72                // if the tick is initialized, run the tick transition
73                if (step.initialized) {
74                    (uint256 feeGrowthGlobal0X128, uint256 feeGrowthGlobal1X128) = zeroForOne
75                        ? (step.feeGrowthGlobalX128, self.feeGrowthGlobal1X128)
76                        : (self.feeGrowthGlobal0X128, step.feeGrowthGlobalX128);
77                    int128 liquidityNet =
78                        Pool.crossTick(self, step.tickNext, feeGrowthGlobal0X128, feeGrowthGlobal1X128);
79                    // if we're moving leftward, we interpret liquidityNet as the opposite sign
80                    // safe because liquidityNet cannot be type(int128).min
81                    unchecked {
82                        if (zeroForOne) liquidityNet = -liquidityNet;
83                    }
84
85                    result.liquidity = LiquidityMath.addDelta(result.liquidity, liquidityNet);
86                }
87
88                unchecked {
89                    result.tick = zeroForOne ? step.tickNext - 1 : step.tickNext;
90                }
91            } else if (result.sqrtPriceX96 != step.sqrtPriceStartX96) {
92                // recompute unless we're on a lower tick boundary (i.e. already transitioned ticks), and haven't moved
93                result.tick = TickMath.getTickAtSqrtPrice(result.sqrtPriceX96);
94            }
95        }

Code Explanation

1. Loop Condition: The loop runs while there is still an amount remaining to swap (amountSpecifiedRemaining != 0) and the current price (result.sqrtPriceX96) hasn't reached the user-specified price limit (params.sqrtPriceLimitX96).
    
2. Step Initialization:
   • step.sqrtPriceStartX96 is set to the current price (result.sqrtPriceX96).
      
3. Finding Next Tick:
   • The next initialized tick in the current direction is found using the tick bitmap. The function nextInitializedTickWithinOneWord returns the next tick that has liquidity and a flag indicating if it's initialized.
   • The next tick is clamped between MIN_TICK and MAX_TICK to avoid exceeding the supported range.
      
4. Price at Next Tick:
   • step.sqrtPriceNextX96 is the price at the next tick, calculated using TickMath.getSqrtPriceAtTick.
      
5. Compute Swap Step:
   • SwapMath.computeSwapStep is called to compute the swap step. It takes:
     • Current price (result.sqrtPriceX96)
     • Target price (the next tick price or the user's price limit, whichever is closer in the swap direction)
     • Current liquidity (result.liquidity)
     • Remaining amount to swap (amountSpecifiedRemaining)
     • The swap fee (swapFee)
   • It returns:
     • New current price after the step (result.sqrtPriceX96)
     • Input amount used in this step (step.amountIn)
     • Output amount produced (step.amountOut)
     • Fee amount (step.feeAmount)
        
6. Update Amounts:

Actually, the initial setting is: int256 amountSpecifiedRemaining = params.amountSpecified; and params.amountSpecified is positive for exact output (meaning we are specifying an exact amount of token to receive) and negative for exact input (meaning we are specifying an exact amount of token to send). 

Therefore, the updates: -

• For an exact output swap (indicated by params.amountSpecified > 0 which means the specified amount is positive for the output token): - 
  • Subtract the output amount of this step from amountSpecifiedRemaining (which is negative for exact output, but note: the subtraction of a positive step.amountOut from a negative amountSpecifiedRemaining would make it less negative, i.e., closer to zero). 
  •  amountCalculated (which tracks the input token) is decreased by the sum of step.amountIn and step.feeAmount (because these are amounts taken from the user, so they are negative for the pool? Actually, we are accumulating the input amount that the user must provide, so we subtract). 
• For an exact input swap (params.amountSpecified <= 0? Actually, the condition is else for params.amountSpecified>0 being exact output, so exact input is the other case): - 
  • amountSpecifiedRemaining (which is positive for exact input) is decreased by the input amount and the fee (so we add the negative of step.amountIn + step.feeAmount to it, but note the code does amountSpecifiedRemaining += (step.amountIn + step.feeAmount).toInt256() which is positive because step.amountIn and step.feeAmount are positive, but amountSpecifiedRemaining is negative? 

Actually, the initial setting is amountSpecifiedRemaining = params.amountSpecified which for exact input is negative. Then in the loop for exact input, we do: amountSpecifiedRemaining += (step.amountIn + step.feeAmount).toInt256()Since step.amountIn + step.feeAmountis positive, adding to a negative number makes it less negative (closer to zero). This is because we are consuming some of the input. However, note the comment in the code: "if exactOutput" condition isparams.amountSpecified>0. So: 

• Exact Output: params.amountSpecified>0 -> amountSpecifiedRemaining is positive? Actually, the initial value is params.amountSpecified which for exact output is positive (the desired output amount). Then in the loop, we subtract the step.amountOut (which is positive) from amountSpecifiedRemaining (so we are reducing the remaining output we need). But wait, the initial comment at the top of the file says:
   
• Exact Output (params.amountSpecified>0): amountSpecifiedRemaining (starts positive) = amountSpecifiedRemaining - step.amountOut (so it becomes less positive) amountCalculated (starts 0) = amountCalculated - (step.amountIn + step.feeAmount) -> becomes negative (because we are accumulating the input token that must be provided)
   
• Exact Input (params.amountSpecified<=0 -> actually negative, so the condition is the else):

amountSpecifiedRemaining (starts negative) = amountSpecifiedRemaining + (step.amountIn + step.feeAmount) -> becomes less negative (because we are consuming input, so we add the positive amount we used in this step to the negative remaining, making it closer to zero)

amountCalculated = amountCalculated + step.amountOut -> becomes positive (because we are accumulating the output token)
 

1. Protocol Fee Handling:
   • If protocolFee is non-zero, we calculate the portion of the fee that goes to the protocol (delta). The calculation depends:
     • If the entire swap fee is the protocol fee (i.e., swapFee == protocolFee), then delta = step.feeAmount (the entire fee goes to protocol).
     • Otherwise, we calculate delta = (step.amountIn + step.feeAmount) * protocolFee / ProtocolFeeLibrary.PIPS_DENOMINATOR. Note: step.amountIn is the amount without the fee, and step.feeAmount is the fee. So the total amount that the user paid in this step is step.amountIn + step.feeAmount. The protocol fee is a percentage of that total.
   • Then we subtract delta from step.feeAmount (so the LP fee is reduced by the protocol fee portion) and add delta to amountToProtocol (a state variable tracking total protocol fees).
      
2. Update Fee Growth Global:
   • If there is liquidity in the current step (result.liquidity > 0), we update the fee growth accumulator for the current step. The formula is: step.feeGrowthGlobalX128 += (step.feeAmount * FixedPoint128.Q128) / result.liquidity
   • This is the fee per unit of liquidity in this step. Note: step.feeAmount is the fee remaining after protocol fee deduction (the LP fee).
      
3. Tick Transition:
   • If the swap step reached the next tick's price (result.sqrtPriceX96 == step.sqrtPriceNextX96), then we need to cross the tick.
     • If the tick is initialized, we cross it by calling Pool.crossTick, which updates the tick and returns liquidityNet (the change in liquidity when crossing the tick).
     • We adjust the liquidity: if moving leftward (i.e., zeroForOne is true) then we negate liquidityNet because the liquidity change is in the opposite direction. Then we update result.liquidity by adding the liquidityNet.
     • Update the current tick: if zeroForOne then we set result.tick = step.tickNext - 1 (because we are now at the tick just below step.tickNext), otherwise result.tick = step.tickNext.
   • If the swap step did not reach the next tick but the price changed, we recalculate the current tick from the new price. This loop continues until the entire amount is swapped or the price limit is hit. Note: The code uses unchecked blocks for gas optimization, but it's safe because the values are constrained by the swap step and the tick boundaries. This is the core of the Uniswap V4 swap mechanism, which is an improvement over V3 by incorporating hooks and dynamic fees, but the fundamental constant product AMM with concentrated liquidity remains.

Post-Swap State Updates

Key Operations Explained:

1. Slot0 Update (Core State)

   COPY

   1self.slot0 = slot0Start.setTick(result.tick)
   2             .setSqrtPriceX96(result.sqrtPriceX96);

   • Stores new tick and sqrtPriceX96 after swap
   • Becomes the new reference point for the pool
      

2. Liquidity Adjustment

   COPY

   1if (self.liquidity != result.liquidity) {
   2    self.liquidity = result.liquidity;
   3}

   • Updates global liquidity if changed during tick crossings
   • Only modifies storage when necessary (gas optimization)
      

3. Fee Accounting

   COPY

   1if (!zeroForOne) {
   2    self.feeGrowthGlobal1X128 = step.feeGrowthGlobalX128;
   3} else {
   4    self.feeGrowthGlobal0X128 = step.feeGrowthGlobalX128;
   5}

   • Stores accumulated fees in the swap direction
   • zeroForOne → update token0 fees (token1 fees for reverse)
      

4. Balance Delta Calculation (Core Accounting)

   COPY

   1if (zeroForOne != (params.amountSpecified < 0)) {
   2    swapDelta = toBalanceDelta(
   3        amountCalculated.toInt128(),
   4        (params.amountSpecified - amountSpecifiedRemaining).toInt128()
   5    );
   6} else {
   7    swapDelta = toBalanceDelta(
   8        (params.amountSpecified - amountSpecifiedRemaining).toInt128(),
   9        amountCalculated.toInt128()
   10    );
   11}

   • Smart Token Assignment:
     • Uses swap direction + sign to determine token flow
     • Handles all 4 swap types with single logic
        

Flash Accounting & Locking

Flash Accounting

In previous versions of Uniswap, every time a swap was made - including multi-hop swap - output tokens had to be transferred out the Pool contract and then transferred into whatever their destination was (next pool in case of multi-hop, or back to the user in case of simple swap).

This design led to inefficiencies because moving tokens around by calling external functions on their smart contracts - especially in a multi-hop swap - was quite expensive. But also, this was the only design possible since each pool was it's own contract and we needed to move tokens in and out of them to keep the logic sound.

With the singleton architecture, a better design now exists - this is called Flash Accounting.

With Flash Accounting, tokens are moved into the PoolManager, all the actions are conducted (single or multi-hop swap), and only the final output tokens need to be withdrawn out of the PoolManager.

As shown in the above diagram, for example - let's say you wanted to swap ETH for DAI. Assuming this requires a multi-hop swap going from ETH to USDC and then from USDC to DAI.
 

In previous versions:

1. ETH is sent to ETH <> USDC pool contract
2. USDC is withdrawn from ETH <> USDC contract and sent to USDC <> DAI contract
3. DAI is withdrawn from USDC <> DAI contract and sent to user
    

In v4, however:

1. ETH is sent to PoolManager
2. PoolManager calculates USDC output amount
3. Without transferring tokens, PoolManager calculates DAI output amount for USDC → DAI swap
4. DAI is withdrawn and sent to user

Therefore we can skip the step of actually calling transfer() on the USDC contract. This same logic also scales further to any swap with an arbitrary number of hops required, and the number of actual token transfers remains constant.
 

Uniswap v4’s concentrated liquidity and flash accounting significantly improve capital efficiency and reduce gas costs. By allowing LPs to target specific price ranges and minimizing token transfers, v4 is poised to dominate DeFi liquidity provision.
 

Capital efficiency in decentralized exchanges is redefined by Uniswap v4's flash accounting and concentrated liquidity. v4 significantly reduces slippage, maximizes fee yields, and lowers gas costs by enabling LPs to target specific price ranges and minimizing needless token transfers. It is the most sophisticated AMM design to date because of its singleton architecture and adjustable hooks, which further increase flexibility.