Inside the pool contract, three key data structures orchestrate this process:

swapCache — a set of static data cached in memory for efficiency. It contains immutable parameters relevant to the swap (starting liquidity, protocol fee settings, and block timestamp). These values remain constant throughout the transaction.

swapState — a dynamic cache tracking live progress: the current tick, the current square-root price (sqrtPriceX96), remaining input/output amounts, and cumulative output so far. As the algorithm iterates through ticks, swapState evolves with every step.

stepComputations — the ephemeral micro-cache used for each individual tick step. It stores transient values: the next tick index, the amount of token in or out for that step, the liquidity at the tick boundary, the next sqrtPriceX96, and a flag indicating whether the next tick is initialized. When a tick is initialized, a “jump” occurs and liquidity instantly changes as the algorithm crosses a range boundary.

Although stepComputations lives only for the duration of each tick iteration, the data it produces is extremely rich. By tracing these internal calculations during swap execution, one can reconstruct micro-level dynamics: how much slippage occurred per tick, how rapidly active liquidity was consumed, and how many tick crossings (and therefore gas-heavy jumps) were required. These traces provide an empirical window into execution quality, liquidity utilization, and the root causes of slippage.

Liquidity as the Determinant of Price Impact

Uniswap V3’s fundamental insight is that price is a derivative of available liquidity. Within any active tick range, swaps obey the constant-product formula just like Uniswap V2, but the size of that mini-pool — its local liquidity — determines how much the price moves per unit traded. Thin liquidity amplifies price movement; dense liquidity dampens it.

Mathematically:

Price Impact = 1 / Active Liquidity

Hence:

More liquidity → smaller price change → lower slippage
Less liquidity → larger price change → higher slippage

Active liquidity is the liquidity available at the range of the current price or tick where trading happens. Only this active slice participates in a swap at any given moment. The inactive ranges remain dormant until the market price migrates into them. Consequently, swap outcomes depend not only on total liquidity but on where that liquidity resides.

From LP Incentives to Liquidity Distribution

Capital efficiency in Uniswap V3 comes from allowing LPs to “concentrate their capital within custom price ranges, achieving higher capital efficiency than V2” (Uniswap Whitepaper, 2021). But capital efficiency means little unless it also yields profit. Since LPs earn fees only when trades occur inside their chosen range, their pursuit of profit dictates how liquidity is distributed. The result is not random; it’s behavioral economics embedded in code.

Gauntlet’s 2022 study found that LPs “tend to concentrate around the current price tick, leading to high depth near spot but thinner tails.” Delchain Research described this as a “clustering” effect where “execution for small trades is excellent, but larger orders face gaps.” Panoptic’s 2023 data went further: fewer than 8% of LPs provide more than 80% of total liquidity, and in some pools, just 1% of LPs control the majority — revealing both concentration and centralization.

This hierarchy of participation produces distinct execution regimes depending on how liquidity is distributed across ticks.

(a) Dense Active Tick Range

When the active tick range is dense, it means multiple LPs have concentrated liquidity tightly around the current tick. This situation is common in stable pairs like USDC/DAI or ETH/USDC, where volatility is low and LPs can confidently expect the price to remain close to its current level for long periods.

For small trades, this is ideal: because the stepComputations within the swap function find abundant liquidity at the current sqrtPriceX96, the price impact per token swapped is tiny. Each step of the swap consumes liquidity smoothly, and the swapState updates gently with minimal slippage. The trader experiences deep liquidity, low price movement, and excellent execution quality.

For large trades, the same density offers partial protection: while the beginning of the trade executes within dense liquidity, as the amount grows, the swap gradually consumes all active liquidity and begins to step into less populated ticks. Once that happens, execution quality drops — not because liquidity disappears, but because each additional step (each new tick crossed) holds progressively less liquidity than the dense band near spot. Thus, even dense active liquidity only supports low-slippage execution up to a limit proportional to its total size. After that limit, the trade suffers incremental slippage as stepComputations cross into thinner zones.

From the LP’s perspective, dense active liquidity represents a competitive zone: many LPs fighting for a share of the same trading volume. Fees per LP may be lower in absolute terms (since they’re divided among many participants), but the fee flow is steady, and capital efficiency remains high because their positions are almost always active.

(b) Thin Active Tick Range

A thin active tick range — where few LPs provide liquidity near the current tick — represents the opposite extreme. This can occur when the market is volatile, or when many LPs have withdrawn or repositioned to safer, wider ranges away from the spot price.

For small trades, the consequences are immediate: the trade begins consuming the limited active liquidity, and the price impact rises sharply even before crossing into new ticks. The swapState’s sqrtPriceX96 moves more steeply per unit of trade, indicating high slippage.

For large trades, the situation worsens drastically. Each step computation must quickly move from one tick to another, finding little liquidity in each range, and triggering multiple jumps. Gas costs rise due to frequent tick crossing, and the resulting price may deviate significantly from the starting price.

In this state, LPs who remain in the active tick range benefit disproportionately. Because all trades must flow through their limited liquidity, they earn very high fees relative to capital deployed — but the user experience for traders deteriorates due to slippage. Thin active ranges thus amplify the asymmetry between LP income and trade quality.

(c) Dense Far-Away Tick Ranges

Sometimes, the current active range is relatively thin, but liquidity exists densely farther away, either above or below the current tick. This can happen when LPs expect a price migration (for instance, anticipating ETH appreciation or a stablecoin depeg). These dense far-away zones represent “liquidity walls” waiting to activate.

For small trades, these distant dense bands are irrelevant, as execution never reaches them. But for large trades that push the price far enough, these zones act as buffers — once stepComputations reach them, slippage slows down because each step now consumes abundant liquidity again. The execution curve flattens temporarily.

However, from a system perspective, this means execution quality across the price range becomes nonlinear — smooth in dense areas, jagged in thin gaps. For LPs in these far-away dense zones, profitability is intermittent: they earn nothing until price migrates into their range, then suddenly capture high fees during active use, before becoming inactive again once the price moves away.

(d) Thin Far-Away Tick Ranges

Finally, the most fragile scenario occurs when both the active tick range and far-away ticks are thin. This patchy distribution often appears after large liquidity withdrawals or in less-traded pools. Both small and large trades then suffer: even modest swaps can move the price meaningfully because every tick holds little liquidity. Execution becomes jumpy, with stepComputations leaping across multiple ticks per trade. Gas usage increases, price discovery worsens, and the pool exhibits low resilience to trading shocks.

From an LP standpoint, this environment is unattractive. Thin far-away ticks earn no fees until price volatility triggers large movements — which may or may not happen. It represents unproductive, idle capital. But because LPs are fee-driven, few are willing to populate these zones unless compensated by volatility or high trading activity.

Summary of Effects

Behavioral Feedback Loop

The loop completes itself: LPs chase fees → they cluster liquidity near expected trading zones → that distribution determines execution quality → traders gravitate toward pools with better execution → which further rewards the clustered LPs.

Meanwhile, distant LPs adapt by widening or repositioning ranges to capture volatility events, perpetuating a dynamic equilibrium of dense centers and thin tails. Over time, this behavior concentrates both liquidity and fee income in a small subset of addresses — Gauntlet’s Pareto finding quantified exactly that.

Thus, the entire swap experience; slippage, gas cost, and execution smoothness is an emergent property of LP fee incentives interacting with Uniswap V3’s tick-based architecture.

Conclusion

Tracing Uniswap V3’s internal swap variables (swapCache, swapState, stepComputations) exposes how liquidity distribution directly shapes swap quality. The staircase metaphor is literal: every step corresponds to a tick, and the height between steps is the price impact. Dense liquidity flattens the steps; thin liquidity makes them steep.

Because LPs earn only when trades use their range, their rational pursuit of fees sculpts the liquidity landscape itself. This self-organizing pattern where dense clusters near spot and thin or speculative tails, explains why small trades experience seamless execution while large trades sometimes face slippage cliffs. In Uniswap V3, the geometry of liquidity is the geometry of price movement, and understanding it requires tracing not just what the swap returns, but how it walks through its steps.

Digital Signature creation process.

• Creating signatures involves hashing the message and then combining this hash (digest) with the private key using ECDSA algorithm; this process is referred to as signing a message.

• Upon signing a message, a signature is created (digital signature) is generated, serving as a means to verify that the signer is indeed the intended account. 

• Each distinct message produces a unique hash called digest.

This is important when considering replay attacks. To prevent replay attack, each signature has to be unique. This is achieved by including a nonce, a number used once, as part of the message. Most times the creation of digital signatures is abstracted away from the user. However, when implementing signatures into a smart contract, extra data including nonce and chain ID should be added to prevent replay attacks.

Simple Signature.

function getSignerSimple(
		uint256 message,
    ) public pure returns (address) {
        bytes32 digest = bytes32(message);
		(uint8 v, bytes32 r, bytes32 s) = vm.sign(privateKey, digest);	// digital signature
        address signer = ecrecover(hashedMessage, v, r, s);
        return signer;
    }

    function verifySignerSimple(
        uint8 _v,
        bytes32 _r,
        bytes32 _s,
        address signer,
		uint256 message,
    ) public pure returns (bool) {
        address actualSigner = getSignerSimple(message, v, r, _s);
        require(signer == actualSigner);
        return true;
    }

This is how signatures used to be constructed for cryptographic authentication purposes. But it comes with a flaw, which is the way it display the data to sign in bytes as it comes with security risk.

EIP-191: Standardizing signatures.

The EIP-191, is a signed data standard that proposes the format for signed data. Unlike the signature creation mechanism explained earlier, that only does arbitrary message hashing. It introduces a standard for signing data.

<prefix> | <1 byte version> | <version specific data> | <data to sign>

Prefix (0x19) - This signifies that the data is a signature. 

1 byte version - The version associated with the sign data.

• 0x00 is the version with an intended validator.

• 0x01 is structured data.

EIP-191 uses 0x00 which is the version with the intended validator.

Data to sign - This is the application specific data or message to sign.

function getSigner191 (
		uint256 message, 
) public view returns (address) {

        // Arguments when calculating hash to validate
		// 0x19  < 1 byte version>  < version specific data>  < data to sign>
        // 1: byte(0x19) - the initial 0x19 byte
        // 2: byte(0) - the version byte
        // 3: version specific data, for version 0, it's the intended validator address
        // 4-6 : Application specific data

        bytes1 prefix = bytes1(0x19);
        bytes1 eip191Version = bytes1(0);	// 0x00
        address indendedValidatorAddress = address(this);
        bytes32 hashMessage = bytes32(message);
        bytes32 digest =
            keccak256(abi.encodePacked(prefix, eip191Version, indendedValidatorAddress, applicationSpecificData));	
		(uint8 v, bytes32 r, bytes32 s) = vm.sign(privateKey, digest);
        address signer = ecrecover(hashedMessage, v, r, s);
        return signer;
    }


function verifySigner191(
		uint256 message,
		uint8 _v,
		bytes32 _r,
		bytes32 _s,
		address signer
)
public view returns (bool) {
		address actualSigner = getSigner191(message, v, r, _s);
		require(signer == actualSigner);
		return true;
}

However if the data to sign is complex, there should be a way to format the data in a readable way, EIP-712.

EIP-712.

Since EIP-191 wasn’t specific enough, the data to sign needed to be easier read and displayed. This EIP proposes a standard for hashing, structuring and signing typed data. Improving ux interaction, readability and specificity to certain contracts. The primary goal is to provide a way to prevent users from misusing signatures, allowing developers to define a clear structure for the data to sign. Due to the inefficiencies of EIP-191, there needed to be a way to send transactions using premade signatures: sponsored transactions.

This standard has a format for signed data:

Prefix 0x19
Version 0x01
DomainSeparator - the hash of the data associated with the version, the domain struct defining the domain of the message being signed.

struct EIP712Domain {
	string name;
	string version;
	uint256 chainId;
	address verifyingContract;
	// bytes32 salt; not required
}

EIP712Domain eip_712_domain_separator_struct = EIP712Domain({
name: "SignatureVerifier", // this can be anything
version: "1", // this can be anything
chainId: 1, // ideally the chainId
verifyingContract: address(this) // ideally, set this as "this", but can be any contract to verify signatures
});

function getSignerEIP712(
		uint256 message, 
) public view returns (address) {
        // Prepare data for hashing
        bytes1 prefix = bytes1(0x19);
        bytes1 eip712Version = bytes1(0x01); // EIP-712 is version 1 of EIP-191
		
		struct Message {
			uint256 number;
			uint256 nonce;	// inserting nonce into every signature prevents replay attacks
		}

		bytes32 public constant MESSAGE_TYPEHASH = keccak256("Message(uint256 number)");
		bytes32 digest = keccak256(abi.encode(MESSAGE_TYPEHASH, Message({ number: message })));
		(uint8 v, bytes32 r, bytes32 s) = vm.sign(privateKey, digest);
        return ecrecover(digest, v, r, s);
    }
}

function verifySignerEIP712(
    uint256 message,
    uint8 _v,
    bytes32 _r,
    bytes32 _s,
    address signer
) public view returns (bool) {
    address actualSigner = getSignerEIP712(message, v, r, _s);
    require(signer == actualSigner);
    return true;
}

EIP-712: OpenZeppelin

It's recommended to use OpenZeppelin libraries as the standard and more secure way to integrate EIP-712 for signature creation and hashing. It comes with the function: _hashTypedDataV4

Create the message type hash and hash it with the message data:

bytes32 public constant MESSAGE_TYPEHASH = keccak256("Message(uint256 message)");

function _hashTypedDataV4(bytes32 hashData) public view returns(bytes32 digest) {
		return keccak256(
			abi.encodePacked(
				"\x19\x01",
                domainSeparator,
				hashData
			)
		)
}

function getMessageHash(Message message) public view returns (bytes32) {
    return _hashTypedDataV4(
        keccak256(
            abi.encode(
                MESSAGE_TYPEHASH,
                message.number,
				message.nonce
            )
        )
    );
}

Retrieve the signer with ECDSA.tryRecover and compare it to the actual signer:

function getSignerOZ(
		uint256 digest, 
		uint8 v, 
		bytes32 r, 
		bytes32 _s
) public pure returns (address) {
    (address signer, /* ECDSA.RecoverError recoverError /, / bytes32 signatureLength */ ) = ECDSA.tryRecover(digest, v, r, _s);
    return signer;
}

function verifySignerOZ(
    uint256 message,
    uint8 _v,
    bytes32 _r,
    bytes32 _s,
    address signer
) public pure returns (bool) {
    address actualSigner = getSignerOZ(getMessageHash(message), v, r, _s);
    require(actualSigner == signer);
    return true;
}

Signature Replay Attack Prevention

As mentioned earlier, EIP-712 is key to preventing replay attacks.

Understanding EIP-191 and EIP-712 is important for understanding how to create replay-resistant data to sign into a signature. The extra data in the structure of EIP-712 ensures replay resistance.

To prevent replay attacks, smart contracts must:

1. Have every signature have a unique nonce that is validated

2. Set and check an expiration date

3. Restrict the s value to a single half

4. Include a chain ID to prevent cross-chain replay attacks

5. Any other unique identifiers (for example, if there are multiple objects to sign in the same contract/chain/etc).

Constructing Signature.

Earlier we mentioned the ux issues solved by EIP-712, and that signatures can constructed off-chain which helps in gas optimization.

Whenever you integrate EIP-712 into a project, how do you construct the signatures off-chain? This section focuses on constructing off-chain signatures using ether.js. We will be working with this project: Airdrop Contract.

import { ethers } from 'ethers';

async function generateSignature(userAddress, amount, merkleAirdropContractAddress) {
  // 1. Connect to the user's wallet
  const provider = new ethers.BrowserProvider(window.ethereum);
  const signer = await provider.getSigner();
  
  // 2. Prepare the domain and types for EIP-712 signature
  const domain = {
    name: "MerkleAirdrop",
    version: "1",
    chainId: await signer.getChainId(),
    verifyingContract: merkleAirdropContractAddress
  };
  
  const types = {
    AirdropClaim: [
      { name: "account", type: "address" },
      { name: "amount", type: "uint256" }
    ]
  };
  
  // 3. Create the value object
  const value = {
    account: userAddress,
    amount: amount
  };
  
  // 4. Request the signature from the user's wallet
  try {
    const signature = await signer.signTypedData(domain, types, value);
    return signature;
  } catch (error) {
    console.error("Error signing typed data:", error);
    throw error;
  }
}

Using the Signature in a function call.

Once you have the signature, you'll need to split it into its components (v, r, s) before calling the claim function:

async function claimAirdrop(userAddress, amount, merkleProof, signature) {
  // Split the signature into v, r, s components
  const sig = ethers.Signature.from(signature);
  
  // Call the contract
  const tx = await merkleAirdropContract.claim(
    userAddress,
    amount,
    merkleProof,
    sig.v,
    sig.r,
    sig.s
  );
  return tx;
}

The above steps and code explained how to construct off-chain signatures in a smart contract that integrates EIP-712.

Conclusion

EIP-712 is a valuable tool for Ethereum developers looking to enhance security and user experience in their dApps. By signing structured data, you reduce the risk of signature misuse and provide clarity to users about what they are signing. As you build and deploy your applications, consider integrating EIP-712 to ensure a safer and more user-friendly experience.

In the link attached, we touched some keywords like: reserve, price, shares, quote, current or total pool liquidity. We used the following Uniswap smart contracts to explain the aforementioned concepts: Uniswap V2 Library, Uniswap V2 Pool contract, and the Uniswap V2 Router contract.

To explain the liquidity concepts in Uniswap V3 for maximum comprehension, we will create a sync with the V2 concepts to further easier the explanation of the V3 concepts.

In Uniswap V2, the pool contract tracks reserves to determine the current pool liquidity and price. We have reserves for token A and B as state variables. While the Uniswap V3 tracks liquidity and price.

To determine the current price of token A in terms of token B, we will divide, Reserve B / Reserve A.

Reserve A - total amount of token X in the pool.
Reserve B - total amount of token Y in the pool.

Using the constant product formula: X * Y = K (invariant).

Price = Y / X.

This represents the spot price of token A in terms of token B.

As mentioned in my article on Uniswap V2, the formula to derive liquidity in Uniswap V2 is:

√xy = L
:: xy = L^2.

Let us put things to perspective as we progress.

The Workings of Uniswap V3.

Uniswap V3 unlike Uniswap V2 aims to enable capital efficiency. Know that Uniswap V2 allows LPs to provide liquidity uniformly across all price ranges in a price curve from 0 to ∞. But it affects capital efficiency because the utilization of liquidity either below or above the current market price is least probable. And LPs only earn swap fees when their capital at a price point is used to facilitate trade. While this creates a passive yield strategy (like the set-and-forget pattern) - as the LPs rely on if the liquidity will be used later - it doesn’t incentivize LPs enough to make markets because their earning capacity is based on chances, and what is the chance that price will fall below or rise above? This is what V3 does significantly as it limits liquidity fragmentation.

For example: A liquidity of $1 million USDC in Uniswap V2 distributed uniformly across all price ranges in a price curve could only facilitate trades of 200 USDC while the same liquidity in a Uniswap V3 pool can facilitate a trade of up to 500,000 USDC. This is what capital efficiency means as it means that LPs earn more swap fees for making markets for volume trades.

This is made possible by an AMM algorithm called Concentrated Liquidity AMM or CLAMM. This enables LPs to provide liquidity in a specific price range. Imagine a ruler, with each line of the centimeter (CM) called tick. If 0 cm to the end (assume 30 cm) is a price curve in a liquidity pool. V3 enables LPs to only provide liquidity in a range, let’s say 10 CM to 15 CM. That is called a price range. Instead of spreading liquidity uniformly to the entire price points, you have the flexibility of determining a tick or price range where you want to concentrate liquidity into. This removes Idle liquidity and creates Liquidity depth because more trades will be facilitated in a price range with more depth than when it’s uniformly distributed.

Also, this means that LPs can only earn swap fees in a range where their liquidity is active. If a large swap occurs that shifts liquidity from the left (lower price range) to the right (upper price range) and it uses up the liquidity in that particular range, it shifts liquidity to the inactive state, that is, LPs will no longer be able to earn fees on their liquidity in that range and leaving it will create impermanent loss. This means, liquidity will no longer be passively managed because the LPs will have to remove their liquidity from an inactive pool thereby avoiding impermanent loss, to an active pool leading to an active management of liquidity. While this creates stress for the LP, it reduces slippage, removes liquidity fragmentation and makes the market efficient.

In addition, this AMM design unlocks a level of possibility where LPs can provide liquidity in a range where the current price on the curve sits above the upper or below the lower range specified by the user. That is what the Uniswap V3 range limit order is all about and LPs can create multiple positions across varying price ranges providing an opportunity to hedge against risks and capture more opportunities.

Note: Liquidity concentrated in a range is called A Position and the tick-based pool functions similarly to Uniswap V2 (mini-V2).

This poses a question, how do you track reserves in a tick-based pool?

Reserves.

Like I said earlier, Reserve is the total amount of token X and token Y in a pool. Since the Uniswap V3 tracks liquidity and price, we can determine reserves using the formula for liquidity and price below..

x.y = L^2
y / x = price

Using the formula for liquidity and price mentioned earlier, let us determine reserve X in the price range.

Math Calculations: Expressing reserve X in terms of L and P.

xy = L^2 ………..eq 1
y / x = price …….eq 2.

y = price x :: px.
Putting y in eq 1.

x (px) = L^2
px^2 = L^2
x^2 = L^2 / p
x = L / √p

Putting the value for x = L / √p in eq 1.

L / √p y = L^2
Ly / √p = L^2
Ly = L^2 √p
y = L^2 √p / L
y = L√p

These are the values of reserve of X and Y of the entire pool.

To factor in the price ranges, the reserve of X will change when all of Y is depleted or when X is in an active range; we can calculate the value for reserve X between the prices Pa and Pb in an active range using the formula:

If x = L / √p
Reserve of X = L / √p - L / √pb

Note: The reserve formula for X is the reserve available for trading in a price range.

Where the reserve of Y is depleted, the current price would have shifted above the upper price.

X = L (1 / √pa  - 1 / √pb).

Since Y is depleted, this can also be likened to the maximum amount of X the price range can  hold or a position can hold.

For Reserve Y.

If y = L√p

y = L√p - L √pa

This is the formula for Y when liquidity is in active range.

Reserve of Y = L(√p - √pa)

However, where X is depleted in the range, the reserve of y is:
Y = L(√pa - √pb).

Note: The following formulas apply to different cases:

x = L / √p - L / √pb
y = L√p - L √pa

1. When you want to derive the amount of X and Y (reserves) backing the current liquidity - it uses the current pool's state.
2. When you want to derive the amount of X or Y to add when adding liquidity to a pool - it uses the user specified ranges.

For case 1:
If the following parameters are true:

L - current liquidity.
p - current price (it could be the lower or upper price if it's an active range.
pb- current upper price of a range.
pa - current lower price of a range.

    function getAmount0ForLiquidity(
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        uint128 liquidity
    ) internal pure returns (uint256 amount0) {
        if (sqrtRatioAX96 > sqrtRatioBX96) (sqrtRatioAX96, sqrtRatioBX96) = (sqrtRatioBX96, sqrtRatioAX96);

        return
            FullMath.mulDiv(
                uint256(liquidity) << FixedPoint96.RESOLUTION,
                sqrtRatioBX96 - sqrtRatioAX96,
                sqrtRatioBX96
            ) / sqrtRatioAX96;
    }

    /// @notice Computes the amount of token1 for a given amount of liquidity and a price range
    /// @param sqrtRatioAX96 A sqrt price representing the first tick boundary
    /// @param sqrtRatioBX96 A sqrt price representing the second tick boundary
    /// @param liquidity The liquidity being valued
    /// @return amount1 The amount of token1
    function getAmount1ForLiquidity(
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        uint128 liquidity
    ) internal pure returns (uint256 amount1) {
        if (sqrtRatioAX96 > sqrtRatioBX96) (sqrtRatioAX96, sqrtRatioBX96) = (sqrtRatioBX96, sqrtRatioAX96);

        return FullMath.mulDiv(liquidity, sqrtRatioBX96 - sqrtRatioAX96, FixedPoint96.Q96);
    }

Note: Based on the formula used to derive the amount of token 0 and token 1 backing a particular amount of pool liquidity. We can equally get the Liquidity backing the given amounts simply by making Liquidity (L) the subject of formula.

Another case is that, we can get the liquidity to add if we have a given amounts desired to add.

If the following parameters is true:

Pa - price lower specified by the user based on the given tick lower.
Pb - price upper specified by the user based on the given tick upper.
Amount0 - amount desired to add for token 0.
Amount1 - amount desired to add for token 1.

    function getLiquidityForAmount0(
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        uint256 amount0
    ) internal pure returns (uint128 liquidity) {
        if (sqrtRatioAX96 > sqrtRatioBX96) (sqrtRatioAX96, sqrtRatioBX96) = (sqrtRatioBX96, sqrtRatioAX96);
        uint256 intermediate = FullMath.mulDiv(sqrtRatioAX96, sqrtRatioBX96, FixedPoint96.Q96);
        return toUint128(FullMath.mulDiv(amount0, intermediate, sqrtRatioBX96 - sqrtRatioAX96));
    }

    /// @notice Computes the amount of liquidity received for a given amount of token1 and price range
    /// @dev Calculates amount1 / (sqrt(upper) - sqrt(lower)).
    /// @param sqrtRatioAX96 A sqrt price representing the first tick boundary
    /// @param sqrtRatioBX96 A sqrt price representing the second tick boundary
    /// @param amount1 The amount1 being sent in
    /// @return liquidity The amount of returned liquidity
    function getLiquidityForAmount1(
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        uint256 amount1
    ) internal pure returns (uint128 liquidity) {
        if (sqrtRatioAX96 > sqrtRatioBX96) (sqrtRatioAX96, sqrtRatioBX96) = (sqrtRatioBX96, sqrtRatioAX96);
        return toUint128(FullMath.mulDiv(amount1, FixedPoint96.Q96, sqrtRatioBX96 - sqrtRatioAX96));
    }

However, while using those formulas to calculate the Liquidity (L) by making it the subject of formula, we can't tell the liquidity to add based on where the current price is in the curve. the code above only gets the liquidity based on which token is dominant in the pool where the other is depleted.

But the code below does justice to deriving Liquidity based on the amounts desired regardless of where price sits in the curve.

    function getLiquidityForAmounts(
        uint160 sqrtRatioX96,
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        uint256 amount0,
        uint256 amount1
    ) internal pure returns (uint128 liquidity) {
        if (sqrtRatioAX96 > sqrtRatioBX96) (sqrtRatioAX96, sqrtRatioBX96) = (sqrtRatioBX96, sqrtRatioAX96);

        if (sqrtRatioX96 <= sqrtRatioAX96) {
            liquidity = getLiquidityForAmount0(sqrtRatioAX96, sqrtRatioBX96, amount0);
        } else if (sqrtRatioX96 < sqrtRatioBX96) {
            uint128 liquidity0 = getLiquidityForAmount0(sqrtRatioX96, sqrtRatioBX96, amount0);
            uint128 liquidity1 = getLiquidityForAmount1(sqrtRatioAX96, sqrtRatioX96, amount1);
			
			// If you follow along with our explanation on Uniswap V2, you would be aware that liquidity is the minimum when compared.
            liquidity = liquidity0 < liquidity1 ? liquidity0 : liquidity1;
        } else {
            liquidity = getLiquidityForAmount1(sqrtRatioAX96, sqrtRatioBX96, amount1);
        }
    }

For case 2:
If the following parameters are true;

L - Liquidity Delta (Liquidity to add or remove)
p - current price (it could be the lower or upper price if it's an active range.
pb - upper price specified by the user based on the tick upper.
pa - lower price specified by the user based on the tick lower.

    function getAmount1Delta(
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        uint128 liquidity,
        bool roundUp
    ) internal pure returns (uint256 amount1) {
        if (sqrtRatioAX96 > sqrtRatioBX96) (sqrtRatioAX96, sqrtRatioBX96) = (sqrtRatioBX96, sqrtRatioAX96);

        return
            roundUp
                ? FullMath.mulDivRoundingUp(liquidity, sqrtRatioBX96 - sqrtRatioAX96, FixedPoint96.Q96)
                : FullMath.mulDiv(liquidity, sqrtRatioBX96 - sqrtRatioAX96, FixedPoint96.Q96);
    }

    /// @notice Helper that gets signed token0 delta
    /// @param sqrtRatioAX96 A sqrt price
    /// @param sqrtRatioBX96 Another sqrt price
    /// @param liquidity The change in liquidity for which to compute the amount0 delta
    /// @return amount0 Amount of token0 corresponding to the passed liquidityDelta between the two prices
    function getAmount0Delta(
        uint160 sqrtRatioAX96,
        uint160 sqrtRatioBX96,
        int128 liquidity
    ) internal pure returns (int256 amount0) {
        return
            liquidity < 0
                ? -getAmount0Delta(sqrtRatioAX96, sqrtRatioBX96, uint128(-liquidity), false).toInt256()
                : getAmount0Delta(sqrtRatioAX96, sqrtRatioBX96, uint128(liquidity), true).toInt256();
    }

Note: If you want to calculate an estimate amounts, the second case does the calculation as it provides the flexibility to choose the rounding direction based on the amounts. There will be a difference in Wei if you use the first case.

The second case is in a function _modifyPosition and even though it's internal, you can copy it for use in your code if you need to make an estimate.

library PositionModifier {

	
	function modifyPosition(ModifyPositionParams memory params)
        public
        noDelegateCall
        returns (
            Position.Info storage position,
            int256 amount0,
            int256 amount1
        )
    {
        checkTicks(params.tickLower, params.tickUpper);

        Slot0 memory _slot0 = pool.slot0(); // SLOAD for gas optimization
        if (params.liquidityDelta != 0) {
            if (_slot0.tick < params.tickLower) {
                // current tick is below the passed range; liquidity can only become in range by crossing from left to
                // right, when we'll need _more_ token0 (it's becoming more valuable) so user must provide it
                amount0 = SqrtPriceMath.getAmount0Delta(
                    TickMath.getSqrtRatioAtTick(params.tickLower),
                    TickMath.getSqrtRatioAtTick(params.tickUpper),
                    params.liquidityDelta
                );
            } else if (_slot0.tick < params.tickUpper) {
                amount0 = SqrtPriceMath.getAmount0Delta(
                    _slot0.sqrtPriceX96,
                    TickMath.getSqrtRatioAtTick(params.tickUpper),
                    params.liquidityDelta
                );
                amount1 = SqrtPriceMath.getAmount1Delta(
                    TickMath.getSqrtRatioAtTick(params.tickLower),
                    _slot0.sqrtPriceX96,
                    params.liquidityDelta
                );

                liquidity = LiquidityMath.addDelta(liquidityBefore, params.liquidityDelta);
            } else {
                // current tick is above the passed range; liquidity can only become in range by crossing from right to
                // left, when we'll need _more_ token1 (it's becoming more valuable) so user must provide it
                amount1 = SqrtPriceMath.getAmount1Delta(
                    TickMath.getSqrtRatioAtTick(params.tickLower),
                    TickMath.getSqrtRatioAtTick(params.tickUpper),
                    params.liquidityDelta
                );
            }
        }
    }


}

Towards the end of this article, you will understand how everything fits in by creating a connection.

Real Reserves Vs Virtual Reserves.

In Uniswap V2, the constant product formula ensures that liquidity is evenly distributed across all price ranges making them fragmented at price points where trading is least probable which makes capital inefficient. As a result, you can’t zoom in to specific price ranges, this makes the concept of concentrated liquidity a significant solution as liquidity is only available in price ranges that liquidity providers choose.

As I earlier said, the Uniswap V3 ticks act like mini-V2s but with concentrated liquidity. Liquidity is only available in ranges where liquidity providers specify. It makes it possible to facilitate trade with less liquidity but with much more efficiency than V2.

For instance, if you want to swap in a range in V2, and liquidity of 10 ETH and 20,000 USDC is provided (Virtual liquidity - liquidity in V2), that would eventually be spread across all price points in the price curve from 0 to ∞. In the Uniswap V3 tick-based system,the same amount won’t be needed to facilitate trade within that range because it’s concentrated, it may require 1 ETH and 2000 USDC (Real liquidity - liquidity in V3 concentrated range) to make the same trade happen. The former explains the concept of Virtual reserves. Uniswap V3 has a formula to calculate the actual amount to be provided or pre-computed just to get the real amount to concentrate in a V3 specific price range. It ensures that the amount of tradable assets of token X and token Y is equal to the real liquidity that has been deposited into only that range. The real liquidity deposited is called the real reserves. If liquidity reaches either bounds of the tokens, they are no more concentrated and liquidity is only in one token. So, virtual reserves make it possible to avoid impermanent loss, or avoid holding just one token and to predict which range to add liquidity into.

Note: Virtual reserves allows the V3 AMM to behave like Uniswap V2 but they don’t represent actual deposited tokens. Real reserves are the actual tokens supplied by LPs.

Price calculations in Uniswap V3?

In Uniswap V2, Price is the value of y / x. But in Uniswap V3, Price is stored as √p (sqrtPriceX96). This is because of precision. In Solidity, 5 / 2 = 2 because the EVM does not store decimal value. But it can be rewritten as 25 / 10 = 2.5. This way, it doesn’t lose its precision and it’s contained with 256 bits. This is how we derive values for less than 1 ether.

For Instance,
1 Ether = 10^18.
0.5 Ether = 5 * 10^17

Now, we have scaled the fractional part of “.5” by 10 ^ 17 to avoid losing precision. Precision is always lost when Solidity doesn’t allow representing fractional numbers.

However, this uses a mathematical notation called “Standard Notation”. This notation scales fractions using decimal (10).

Uniswap uses “Q Notation”, this type scales fractions using binary. It now depends on how many bits you want to scale by.

For instance, assuming we want to scale 1.5 in Q notation format by 8 bits, that is Q8.

1 * 2^8 = 256

0.5 * 2^8 = 128

Total is 384 in Q notation. The fraction has been converted to an integer without losing its precision. We can always get our value back by dividing by 2^8. Why this is easy for Uniswap to use is because the multiplication and division operations can be performed using bit shifting operations.

E.g. X * 2^n = x << n

Q number notation is usually written as Qm.n, where m = the integer part and n is the fractional part, that we are trying to scale.

Earlier, we used Q8. If we write it using the Qm.n format, we can write Q8.8, the integer value must contain 8 bits and the fraction can be scaled using binary scaling by bits.

QX96 used by Uniswap means the fraction is scaled by 96 bits. So we can express 1.5X96 as 1.5 * 2 ^96 or 1.5 << 96 but to store Q8.8 in a solidity integer, we need 8 + 8 = 16 bits because it’s both the integer and fractional bits that we want to store. This perfectly fits into uint16 or max uint256, which is uint16 variableX16.

To get the sqrtPriceX96 used in Uniswap, we will use the spot price of an AMM, Y / X.

If token X is 500 and token Y is 20.
Price is 500 / 20 = 25.
So, the price is 25.
SqrtPrice: √25 = 5
SqrtPriceX96: 5 * 2 ^96.

Since we scale the fractional part by 96, Uniswap stores the integer in a uint160 SqrtPriceX96 variable to make up the max number of bits of an unsigned integer in Solidity. This adds to optimize gas by storing all the state variables in the first slot - slot0.

Adding Liquidity.

When providing liquidity, like in Uniswap V2, we specify the token amounts to send to the pool as liquidity, these are the desired amounts. Then it maps the amounts of both tokens to a certain amount of liquidity to ensure that we can re-compute the delta for those amounts.

Note: Liquidity, in the context of AMMs, measures the combined reserves of the token pair x and y.

For instance, amount0Desired → amount1Desired → liquidity.

The liquidity is also called Liquidity Delta. Delta is a financial term used to describe the amount needed to move an asset from point A to point B.

What Uniswap does is that it first calculates the liquidity delta for the amounts to be provided. And then re-calculate the delta of both amount 0 and amount1. Now, this calculation might be  seen as circling about but it’s needed because using the amounts desired, you can’t know where price sits in the curve if the amountsDelta is not computed from the liquidity.

Let’s examine the following smart contract that is put together to ensure we provide liquidity the Uniswap way.

Pool.sol
LiquidityManagement.sol
NonfungiblePositionManager.sol

Before we dive deep, keep in mind that a Uniswap V3 Position is an object:

Position – > {
tickLower;
tickUpper;
liquidityDelta;
}

To create a position by supplying liquidity, it’s important to know the pool state, especially the current tick of the pool.

If the current tick of the pool is less than the tick Lower, then the pool is out of range.
If the current tick of the pool is greater than the tick Upper, then the pool is out of range.
If the current tick of the pool is less than the tick Upper, then the pool is in the active range.

When a pool is in active range, we can supply amount0Delta and amount1Delta
When a pool tick is less than the tickLower, then we can only supply the amount0Delta because that’s the amount depleted in the pool.
When a pool tick is greater than the tickUpper, then we can only supply the amount1Delta because that’s the amount depleted in the pool.

The amountsDelta are the amount required to shift the pool price from point A to point B. Uniswap uses the same formula mentioned earlier to calculate the estimated amounts required to shift the range from price lower to upper.

Estimated amountdelta of X and Y.

x = L / √pL - L / √pU. --> amount0Delta
y = L√pU - L √pL -->. amount1Delta

Although, they are used in different contexts that require different parameters. We use the price lower and price upper specified by the user to calculate the estimates here whenever we want to add liquidity.

Let’s check the code.

The mint function is the core function that mints liquidity to an LP after confirming the Balance updates. It calls the `_modifyPosition` function which does modify liquidity(either adding or removing) which is + or - liquidityDelta which is a int256 type. Note that the delta value returned (amount0Int and amount1Int) is pre-computed and hasn't been sent into the pool until the uniswapV3MintCallback is called.

    function mint(
        address recipient,
        int24 tickLower,
        int24 tickUpper,
        uint128 amount,
        bytes calldata data
    ) external override lock returns (uint256 amount0, uint256 amount1) {
        require(amount > 0);
        (, int256 amount0Int, int256 amount1Int) =
            _modifyPosition(
                ModifyPositionParams({
                    owner: recipient,
                    tickLower: tickLower,
                    tickUpper: tickUpper,
                    liquidityDelta: int256(amount).toInt128()
                })
            );

        amount0 = uint256(amount0Int);
        amount1 = uint256(amount1Int);

        uint256 balance0Before;
        uint256 balance1Before;
        if (amount0 > 0) balance0Before = balance0();
        if (amount1 > 0) balance1Before = balance1();
        IUniswapV3MintCallback(msg.sender).uniswapV3MintCallback(amount0, amount1, data);
        if (amount0 > 0) require(balance0Before.add(amount0) <= balance0(), 'M0');
        if (amount1 > 0) require(balance1Before.add(amount1) <= balance1(), 'M1');

        emit Mint(msg.sender, recipient, tickLower, tickUpper, amount, amount0, amount1);
    }

The _modifyPosition function then confirms if the liquidityDelta is non-zero, and as we said earlier a position comprises the tick lower and upper, we must confirm the pool state by checking in the slot0 variable to check where the current pool tick is placed. If it's lesser than the specified tick lower (out of range) or greater than the tick Upper(out of range) or less than the tick Upper (in active range). That is the conditional branching you can see in the code to determine which token and amountDelta will be transferred to the pool.

Note: The amountDelta returned here (amount0Int and amount1Int) can only be positive when adding liquidity.

Amount Owed in this context is the amount0Delta pre-calculated to be sent to the pool and it must be greater than 0 when adding liquidity. Basically, it means you owe the pool some amounts of liquidity to be sent.

When removing liquidity, I call the delta amounts, amount owned, that is the amount the pool owe you when removing liquidity.

For context, see the Uniswap's comment in the code below.

	/// @dev Effect some changes to a position
	/// @param params the position details and the change to the position's liquidity to effect
	/// @return position a storage pointer referencing the position with the given owner and tick range
	/// @return amount0 the amount of token0 owed to the pool, negative if the pool should pay the recipient
	/// @return amount1 the amount of token1 owed to the pool, negative if the pool should pay the recipient
    

	function _modifyPosition(ModifyPositionParams memory params)
        private
        noDelegateCall
        returns (
            Position.Info storage position,
            int256 amount0,
            int256 amount1
        )
    {
        checkTicks(params.tickLower, params.tickUpper);

        Slot0 memory _slot0 = slot0; // SLOAD for gas optimization

        position = _updatePosition(
            params.owner,
            params.tickLower,
            params.tickUpper,
            params.liquidityDelta,
            _slot0.tick
        );

        if (params.liquidityDelta != 0) {
            if (_slot0.tick < params.tickLower) {
                // current tick is below the passed range; liquidity can only become in range by crossing from left to
                // right, when we'll need _more_ token0 (it's becoming more valuable) so user must provide it
                amount0 = SqrtPriceMath.getAmount0Delta(
                    TickMath.getSqrtRatioAtTick(params.tickLower),
                    TickMath.getSqrtRatioAtTick(params.tickUpper),
                    params.liquidityDelta
                );
            } else if (_slot0.tick < params.tickUpper) {
                // current tick is inside the passed range
                uint128 liquidityBefore = liquidity; // SLOAD for gas optimization

                // write an oracle entry
                (slot0.observationIndex, slot0.observationCardinality) = observations.write(
                    _slot0.observationIndex,
                    _blockTimestamp(),
                    _slot0.tick,
                    liquidityBefore,
                    _slot0.observationCardinality,
                    _slot0.observationCardinalityNext
                );

                amount0 = SqrtPriceMath.getAmount0Delta(
                    _slot0.sqrtPriceX96,
                    TickMath.getSqrtRatioAtTick(params.tickUpper),
                    params.liquidityDelta
                );
                amount1 = SqrtPriceMath.getAmount1Delta(
                    TickMath.getSqrtRatioAtTick(params.tickLower),
                    _slot0.sqrtPriceX96,
                    params.liquidityDelta
                );

                liquidity = LiquidityMath.addDelta(liquidityBefore, params.liquidityDelta);
            } else {
                // current tick is above the passed range; liquidity can only become in range by crossing from right to
                // left, when we'll need _more_ token1 (it's becoming more valuable) so user must provide it
                amount1 = SqrtPriceMath.getAmount1Delta(
                    TickMath.getSqrtRatioAtTick(params.tickLower),
                    TickMath.getSqrtRatioAtTick(params.tickUpper),
                    params.liquidityDelta
                );
            }
        }
    }

The LiquidityManagement contract in Uniswap V3 manages liquidity.

The flow:
- The LP sends in the amount0Desired and amount1Desired.
- Earlier we said, these amounts map to a liquidityDelta which is the amount of liquidity required to change the pool's original liquidity. It is delta because we could either add or remove liquidity.
- The liquidityDelta is sent to the pool to pre-calculate the amountsDelta (amount0, amount1) = pool.mint
- The pool calls back the `uniswapV3MintCallback` to pay the pre-calculated amounts `pay(decoded.poolKey.token0, decoded.payer, msg.sender, amount0Owed);`
- The CallbackValidation.verifyCallback(factory, decoded.poolKey) verifies the caller is the pool.
- In this case, amount0Owed > 0 must be true because LiquidityDelta is positive when we want to add liquidity.

abstract contract LiquidityManagement is IUniswapV3MintCallback, PeripheryImmutableState, PeripheryPayments {
    struct MintCallbackData {
        PoolAddress.PoolKey poolKey;
        address payer;
    }

    /// @inheritdoc IUniswapV3MintCallback
    function uniswapV3MintCallback(
        uint256 amount0Owed,
        uint256 amount1Owed,
        bytes calldata data
    ) external override {
        MintCallbackData memory decoded = abi.decode(data, (MintCallbackData));
        CallbackValidation.verifyCallback(factory, decoded.poolKey);

        if (amount0Owed > 0) pay(decoded.poolKey.token0, decoded.payer, msg.sender, amount0Owed);
        if (amount1Owed > 0) pay(decoded.poolKey.token1, decoded.payer, msg.sender, amount1Owed);
    }

    struct AddLiquidityParams {
        address token0;
        address token1;
        uint24 fee;
        address recipient;
        int24 tickLower;
        int24 tickUpper;
        uint256 amount0Desired;
        uint256 amount1Desired;
        uint256 amount0Min;
        uint256 amount1Min;
    }

    /// @notice Add liquidity to an initialized pool
    function addLiquidity(AddLiquidityParams memory params)
        internal
        returns (
            uint128 liquidity,
            uint256 amount0,
            uint256 amount1,
            IUniswapV3Pool pool
        )
    {
        PoolAddress.PoolKey memory poolKey =
            PoolAddress.PoolKey({token0: params.token0, token1: params.token1, fee: params.fee});

        pool = IUniswapV3Pool(PoolAddress.computeAddress(factory, poolKey));

        // compute the liquidity amount
        {
            (uint160 sqrtPriceX96, , , , , , ) = pool.slot0();
            uint160 sqrtRatioAX96 = TickMath.getSqrtRatioAtTick(params.tickLower);
            uint160 sqrtRatioBX96 = TickMath.getSqrtRatioAtTick(params.tickUpper);

            liquidity = LiquidityAmounts.getLiquidityForAmounts(
                sqrtPriceX96,
                sqrtRatioAX96,
                sqrtRatioBX96,
                params.amount0Desired,
                params.amount1Desired
            );
        }

        (amount0, amount1) = pool.mint(
            params.recipient,
            params.tickLower,
            params.tickUpper,
            liquidity,
            abi.encode(MintCallbackData({poolKey: poolKey, payer: msg.sender}))
        );

        require(amount0 >= params.amount0Min && amount1 >= params.amount1Min, 'Price slippage check');
    }
}

The actual contract to call whenever an LP wants to add liquidity is the NonfungibleManager.sol. It has an external mint function that calls into the addLiquidity function in the LiquidityManagement.sol contract.

    /// @inheritdoc INonfungiblePositionManager
    function mint(MintParams calldata params)
        external
        payable
        override
        checkDeadline(params.deadline)
        returns (
            uint256 tokenId,
            uint128 liquidity,
            uint256 amount0,
            uint256 amount1
        )
    {
        IUniswapV3Pool pool;
        (liquidity, amount0, amount1, pool) = addLiquidity(
            AddLiquidityParams({
                token0: params.token0,
                token1: params.token1,
                fee: params.fee,
                recipient: address(this),
                tickLower: params.tickLower,
                tickUpper: params.tickUpper,
                amount0Desired: params.amount0Desired,
                amount1Desired: params.amount1Desired,
                amount0Min: params.amount0Min,
                amount1Min: params.amount1Min
            })
        );

        _mint(params.recipient, (tokenId = _nextId++));

        bytes32 positionKey = PositionKey.compute(address(this), params.tickLower, params.tickUpper);
        (, uint256 feeGrowthInside0LastX128, uint256 feeGrowthInside1LastX128, , ) = pool.positions(positionKey);

        // idempotent set
        uint80 poolId =
            cachePoolKey(
                address(pool),
                PoolAddress.PoolKey({token0: params.token0, token1: params.token1, fee: params.fee})
            );

        _positions[tokenId] = Position({
            nonce: 0,
            operator: address(0),
            poolId: poolId,
            tickLower: params.tickLower,
            tickUpper: params.tickUpper,
            liquidity: liquidity,
            feeGrowthInside0LastX128: feeGrowthInside0LastX128,
            feeGrowthInside1LastX128: feeGrowthInside1LastX128,
            tokensOwed0: 0,
            tokensOwed1: 0
        });

        emit IncreaseLiquidity(tokenId, liquidity, amount0, amount1);
    }

Conclusion:

Uniswap V3 introduces a groundbreaking approach to liquidity provision through its Concentrated Liquidity Market Maker (CLAMM) model, significantly enhancing capital efficiency compared to Uniswap V2. By allowing liquidity providers (LPs) to concentrate their funds within specific price ranges (ticks), Uniswap V3 ensures that liquidity is deployed where it is most likely to be utilized, reducing idle capital and maximizing fee earnings for active market makers.

Key takeaways include:

1. Capital Efficiency: Unlike V2, where liquidity is spread uniformly across all price ranges, V3 enables LPs to allocate funds to targeted price intervals. This means the same amount of capital can facilitate larger trades within a specified range, improving capital utilization and reducing slippage.

2. Tick-Based System: Liquidity in V3 is managed within discrete price ranges (ticks), functioning like mini-V2 pools but with concentrated depth. This allows LPs to create multiple positions, hedge risks, and implement advanced strategies such as limit orders.

3. Reserves & Price Calculation: V3 tracks liquidity (L) and price (√P) rather than raw reserves. Virtual reserves ensure that liquidity behaves like a traditional AMM within an active range while optimizing gas and precision using Q notation (sqrtPriceX96).

4. Active Liquidity Management: LPs must monitor their positions and adjust liquidity as price moves out of their designated range to remain active and earn fees. This shifts liquidity provision from a passive to a more active strategy.

5. Minting Liquidity: Adding liquidity in V3 involves specifying a price range, calculating liquidity delta (L), and pre-computing token amounts (amount0Delta and amount1Delta) to ensure optimal capital allocation. The NonfungiblePositionManager facilitates this process, minting NFTs representing LP positions.

Uniswap V3’s innovations make it a powerful tool for both retail and professional liquidity providers, offering greater control, efficiency, and earning potential. However, this comes with increased complexity, requiring LPs to actively manage their positions to maximize returns. By understanding these core concepts—liquidity concentration, tick-based pricing, and virtual reserves—users can better navigate Uniswap V3’s advanced features and leverage its capabilities for decentralized market-making.

The evolution from V2 to V3 marks a significant step forward in decentralized finance (DeFi), paving the way for more sophisticated and capital-efficient AMM designs in the future.

Uniswap V2 is one of the most popular decentralized exchanges that relies on the Automated Market Maker (AMM) principles to facilitate interaction with decentralized pools of liquidity either by trading, or earning yield from liquidity provision. 

DeFi protocols like Uniswap rely on precise mathematical models to calculate user shares, distribute profits and maintain pool balance.

Fundamental to these protocols is the concept of user shares — the proportional ownership of assets in a pool — and the mechanism of profit distribution.

In this article, I provide an in-depth explanation of the mechanisms, math, and processes used in these protocols for share, profit calculation and pool rebalancing.

Shares in DeFi

Shares in DeFi protocols represent ownership or a claim to a portion of pooled assets. These shares track user contributions relative to the pool, determine user entitlement to profits. It simplifies proportional ownership in scenarios with many participants. In Uniswap V2, shares represent a user’s liquidity in token pairs.

AMM-based Share Calculation.

When liquidity providers deposit tokens into a uniswap pool, they receive liquidity provider (LP) tokens as proof of ownership which entitles them to:

1. A share of the pool’s trading fees.

2. A proportional claim on the pool’s reserves or total liquidity.

The value of a pool changes based on market conditions — deposits, withdrawals, trading fees.

Mint Pool Share Math.

In a single token pool, when the total deposits match the pool’s reserves or total liquidity, the amount of shares to mint can be calculated based on ratio 1:1.

Example 1: 
User A deposits 300 usdc in a pool.
User B deposits 500 usdc in a pool.
User C deposits 200 usdc in a pool.

The pool’s value is 1000 usdc. 
The shares to mint is ratio-based, 1:1, because;

Total liquidity provided = The pool’s total liquidity or reserves.
The shares to mint per user = 1000 total deposits/1000 total liquidity.

Supposing each user add 1 usdc to the pool, they get 1 shares minted to them each. 

Though, the shares to mint is calculated based on the users total deposits. The shares to mint of a user who provided 300 usdc to the pool will be 300 shares.

LP tokens are minted based on the ratio of the liquidity provided by the user compared to the total liquidity in the pool.

Example 2: 
If the pool profits 100 usdc from a yield bearing vault, now the total deposits is not equal to the pool value since the pool has generated 100 usdc profit which totals to 1,100 usdc.

If a User D deposits 110 usdc, the total deposited changes forwad. 
To calculate the shares to mint, 
T — Total shares minted
S — Shares to mint
L0 — Value of the pool before deposit
L1 — Value of the pool after deposit

Unlike the previous example where no share has been minted because it was based on first deposit, we assume T > 0.

Shares to mint = L1 — L0/L0 * T

The value of the pool could be derived using the balance of tokens deposited in the pool or it could be derived in other ways since the pool could generate some yield.

The percentage of shares to mint should be proportional to the percentage increase from L0 to L1. The amount of shares to mint should equally be proportional to the change in increase.

Let us put numbers into the formula.

If L0 = 1100, L1 = 1210, T = 1000, S = ?

S = L1-L0/L0 T
1210–1100/1100 1000
Shares to mint = 100 LP tokens.

The same ratio applies to calculate token B.

Pool Tokens Amounts Math.

Unlike the single token pool which could have a yield generation strategy contract deployed separately for it to generate profit for the pool which is proportionally distributed across all liquidity providers. Uniswap V2 generates profits through a fee-based exchange mechanism that allows a user to trade tokens which is proportionally distributed to liquidity providers.

Uniswap V2 pool is designed in such a way that its pool manages two tokens, token X and token Y, for the exchange to occur. Similar to the traditional exchange market, the exchange rate is the price of exchange for the desired token. For the exchange to occur, the two tokens must be available in Uniswap V2 pool, which is provided by a liquidity provider. The responsibility of a liquidity provider is to create a liquidity pool or add to an existing pool which is ratio-based. The idea of a ratio-based pool is that the ratio of token X and token Y in the pool is able to efficiently cater for traders who desire either token. This ratio is set when creating a liquidity pool, it is simply the amount of both tokens added at the point of creation. 

Uniswap does not allow adding arbitrary amounts of tokens as liquidity unless it is proportional to the ratio of tokens in the pool. To determine the amount of liquidity to provide, let’s consider:

1. The pool’s reserve.

2. The spot price.

The pool’s reserve is the total amount of token X and token Y in a Uniswap pool sufficient to efficiently enable traders to swap. The ratio of the reserve is used to determine the price of tokens. The concept of price is such that without price you cannot know the value of something (token X or token Y) added to a pool, in other words, the price of tokens is used to determine the optimal amounts of tokens that can added to the pool.

Note: When the value(liquidity) of token X or token Y is added to a pool at a certain price, it is distributed evenly along every possible price curve.

For example, if an LP provides 10 ETH and 10,000 USDT, the liquidity is added across the entire price curve, which includes prices like:

1 ETH = 500 USDT (low price)
1 ETH = 5,000 USDT (high price)

And every possible price in between. Even if the current market price of ETH is 1 ETH = 1,000 USDT, some of the liquidity is allocated to very low prices (e.g., 1 ETH = 500 USDT) and very high prices (e.g., 1 ETH = 5,000 USDT). If trading doesn't occur at those price ranges, the liquidity spread to that price range stays at that price until a swap occur otherwise the value remain unused (fragmented).

So, to keep the price constant, since price only changes when a swap occurs and not when liquidity is provided, the ratio of liquidity to provide must equal the ratio of the pool’s reserves.

Mathematically,

Price = Token X Reserve / Token Y Reserve.

If we have 1 million dai and 2,000 eth in a pool. 

Price of token Y = 1 million DAI / 2,000 ETH.

Therefore, Price of token Y in terms of token X= 500 DAI per ETH.

Note: This is the spot price of token Y in terms of token X. 

The price of tokens after adding liquidity = The price of tokens before adding liquidity.

X0 — amount of token X before adding liquidity.
Y0 — amount of token Ybefore adding liquidity.
ΔX — amount of token X to add as liquidity.
ΔY  — amount of token Y to add as liquidity.

ΔX/ΔY = X/Y

Uniswap operates using the constant product AMM where X * Y= K

It says, liquidity must be added in proportion to the pool’s current reserves, ensuring X and Y remain in the correct ratio. This is because any imbalance would break the constant product invariant.

Therefore, X/Y represents the spot price. 
Equally, ΔX/ΔY represents the spot price since the price doesn’t change based on the given ratio applied even after adding liquidity.

The spot price is derived from the ratio of the tokens reserves. It is the price of the tokens in the Uniswap pool which does not reflect external price unless an arbitrage occurs to even the prices.

The formula shows that to keep the price constant, using the same ratio we must optimally derive how much of token X and Y to provide.

Expanding the formula, Y+ ΔY/ X + ΔX = X / Y
Y.ΔY = X.ΔX
ΔX/ΔY = X / Y satisfies the equation above.

So to calculate the amount of token X to add:
ΔX = Y.ΔY / X

using this formula, we can derive the optimal amount of token X to add to the pool.

you can find this in the uniswap code:

    function quote(uint amountA, uint reserveA, uint reserveB) internal pure returns (uint amountB) {
        require(amountA > 0, 'UniswapV2Library: INSUFFICIENT_AMOUNT');
        require(reserveA > 0 && reserveB > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
        amountB = amountA.mul(reserveB) / reserveA;
    }

In a scenario where the deposited tokens or liquidity doesn’t match the correct ratio.

1. Uniswap adjusts your deposit to fit the correct ratio.

2. Uniswap will use only the amount required to match the pool ratio and refund excess amount of tokens.

3. You will receive fewer LP tokens since only the portion of tokens that optimally fit the correct ratio is used to provide liquidity.

Pool Shares Math.

Uniswap uses a math function to represent the total amount of Liquidity in the pool, 

f(x,y) = L

also, uniswap uses the square of x and y to represent liquidity.

i.e. √x.y = L

in other words, f(x,y) = √x.y.
x and y — the pool reserves of tokens
L — the total liquidity tokens minted or that LPs hold altogether.

see the uniswap code:

        uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
        if (_totalSupply == 0) {
            liquidity = Math.sqrt(amount0.mul(amount1)).sub(MINIMUM_LIQUIDITY);
           _mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens

    // this low-level function should be called from a contract which performs important safety checks
    function mint(address to) external lock returns (uint liquidity) {
        (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
        uint balance0 = IERC20(token0).balanceOf(address(this));
        uint balance1 = IERC20(token1).balanceOf(address(this));
        uint amount0 = balance0.sub(_reserve0);
        uint amount1 = balance1.sub(_reserve1);

        bool feeOn = _mintFee(_reserve0, _reserve1);
        uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
        if (_totalSupply == 0) {
            liquidity = Math.sqrt(amount0.mul(amount1)).sub(MINIMUM_LIQUIDITY);
           _mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens
        } else {
            liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);
        }
        require(liquidity > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_MINTED');
        _mint(to, liquidity);

        _update(balance0, balance1, _reserve0, _reserve1);
        if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
        emit Mint(msg.sender, amount0, amount1);
    }

Don’t forget — For optimal liquidity addition, the ratio of the deposited tokens must match the current pool ratio.

Δx/Δy​=x/y

If √x.y = L is the total liquidity LP’s collectively hold before adding liquidity.
Then, √x1.y1 = L1 is the total liquidity LP’s collectively hold after adding liquidity.

So, L1 — L = LP’s token amount.

LP’s token amount/L1 * T = LP’s pool share.

Example 3:
If the reserves of two tokens in a pool are 1000 and 500 respectively.
The ratio is 1000:500 = 2:1

Supposing you deposit 200 amount of token X and token Y
To maintain the 2:1 ratio , token X optimally fits the pool ratio but we need 100 amount of token Y to match the ratio.

So, uniswap will calculate the amount of token Y to add to the pool optimally and refund the remaining 100 tokens.

you can find this in the uniswap code:

(uint reserveA, uint reserveB) = UniswapV2Library.getReserves(factory, tokenA, tokenB);
        if (reserveA == 0 && reserveB == 0) {
            (amountA, amountB) = (amountADesired, amountBDesired);
        } else {
            uint amountBOptimal = UniswapV2Library.quote(amountADesired, reserveA, reserveB);
            if (amountBOptimal <= amountBDesired) {
                require(amountBOptimal >= amountBMin, 'UniswapV2Router: INSUFFICIENT_B_AMOUNT');
                (amountA, amountB) = (amountADesired, amountBOptimal);

    function _addLiquidity(
        address tokenA,
        address tokenB,
        uint amountADesired,
        uint amountBDesired,
        uint amountAMin,
        uint amountBMin
    ) internal virtual returns (uint amountA, uint amountB) {
        // create the pair if it doesn't exist yet
        if (IUniswapV2Factory(factory).getPair(tokenA, tokenB) == address(0)) {
            IUniswapV2Factory(factory).createPair(tokenA, tokenB);
        }
        (uint reserveA, uint reserveB) = UniswapV2Library.getReserves(factory, tokenA, tokenB);
        if (reserveA == 0 && reserveB == 0) {
            (amountA, amountB) = (amountADesired, amountBDesired);
        } else {
            uint amountBOptimal = UniswapV2Library.quote(amountADesired, reserveA, reserveB);
            if (amountBOptimal <= amountBDesired) {
                require(amountBOptimal >= amountBMin, 'UniswapV2Router: INSUFFICIENT_B_AMOUNT');
                (amountA, amountB) = (amountADesired, amountBOptimal);
            } else {
                uint amountAOptimal = UniswapV2Library.quote(amountBDesired, reserveB, reserveA);
                assert(amountAOptimal <= amountADesired);
                require(amountAOptimal >= amountAMin, 'UniswapV2Router: INSUFFICIENT_A_AMOUNT');
                (amountA, amountB) = (amountAOptimal, amountBDesired);
            }
        }
    }

Adding Liquidity to Uniswap V2:

The main entry point to add liquidity to Uniswap V2 pool is the addLiquidity function in the periphery contract.

    function addLiquidity(
        address tokenA,
        address tokenB,
        uint amountADesired,
        uint amountBDesired,
        uint amountAMin,
        uint amountBMin,
        address to,
        uint deadline
    ) external virtual override ensure(deadline) returns (uint amountA, uint amountB, uint liquidity) {
        (amountA, amountB) = _addLiquidity(tokenA, tokenB, amountADesired, amountBDesired, amountAMin, amountBMin);
        address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
        TransferHelper.safeTransferFrom(tokenA, msg.sender, pair, amountA);
        TransferHelper.safeTransferFrom(tokenB, msg.sender, pair, amountB);
        liquidity = IUniswapV2Pair(pair).mint(to);
    }

Here is how it works:

- It calls the internal function _addLiquidity explained earlier which does the ratio calculation and the optimal amounts to add.

- It transfers the tokens to the pair contract.

- It mints liquidity to the user.

Key Takeaways:

Shares in Uniswap V2: Represented by LP tokens, which track user contributions to the pool.

Profit Mechanism: Profits from trading fees are embedded in the value of LP tokens.

Fee Distribution: Automatically proportional to LP tokens held.

Dynamic Rebalancing: Ensured by the constant product formula.

Conclusion:

The Uniswap V2's mechanisms for calculating shares and distributing profits create a seamless, decentralized experience for liquidity providers. The protocol simplifies ownership tracking, and by leveraging its constant product formula ensures efficient pool rebalancing and fee collection. Understanding these mechanisms enables LPs to make informed decisions and optimize their DeFi strategies.

The Workings of Permit2.

1. The user initiates a normal token approval to the permit2 contract and by doing so, they have granted permission to the permit2 contract to be able to spend their tokens on their behalf.
2. The user signs a gasless off-chain permit message expressing their intents to modify their permission.
3. The application takes the permit message and delivers to the permit2 contract informing it of the user’s intent.
4. The permit2 contract then verifies that signature is from the actual signer and does transfer of tokens to the actual spender which is the application.

Building a simple Permit2 contract.

Permit2 smart contract has two token approval mechanisms - allowance transfer and signature transfer.

In this section, we will explore the signature transfer mechanism and build a simple permit2 smart contract to understand the flow of the perrmit2 contract.

This section requires the user to have a knowledge of EIP-712 which is a signature standard for typed structured data for the off-chain signature mechanism to express intents.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/EIP712.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/ECDSA.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol";

contract SimplePermit2 is EIP712 {
    using ECDSA for bytes32;

    struct TokenPermissions {
        address token;
        uint256 amount;
    }

    struct PermitTransferFrom {
        TokenPermissions permitted;
        uint256 nonce;
        uint256 deadline;
    }

    struct SignatureTransferDetails {
        address to;
        uint256 requestedAmount;
    }

    bytes32 private constant _PERMIT_TRANSFER_FROM_TYPEHASH =
        keccak256("PermitTransferFrom(TokenPermissions permitted, address spender, uint256 nonce, uint256 deadline)TokenPermissions(address token,uint256 amount)");

    bytes32 public constant _TOKEN_PERMISSIONS_TYPEHASH = keccak256("TokenPermissions(address token,uint256 amount)");

    constructor() EIP712("SimplePermit2", "1") {}

    function permitTransferFrom(
        PermitTransferFrom memory permit,
        SignatureTransferDetails calldata transferDetails,
        address owner,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) public view  {
        bytes memory signature = bytes.concat(r, s, bytes1(v));
        
        uint256 requestedAmount = transferDetails.requestedAmount;

        if (block.timestamp > permit.deadline) revert SignatureExpired(permit.deadline);
        if (requestedAmount > permit.permitted.amount) revert InvalidAmount(permit.permitted.amount);

        permit.nonce++;

        signature.verify( _hashTypedData(getHashData(permit)), owner);

        ERC20(permit.permitted.token).safeTransferFrom(owner, transferDetails.to, requestedAmount);
    }

    function getHashData(
        PermitTransferFrom memory permit
    ) public view returns (bytes32) {

        bytes32 tokenPermissionHash = keccak256(
                abi.encode(_TOKEN_PERMISSIONS_TYPEHASH, permit.permitted)
            );

        return keccak256(
                    abi.encode(
                        _PERMIT_TRANSFER_FROM_TYPEHASH,
                        keccak256(abi.encodePacked(tokenPermissionHash)),
                        msg.sender,
                        permit.nonce,
                        permit.deadline
                    )
                );
    }

    function verify(
        bytes calldata signature,
        bytes32 digest,
        address claimedSigner,
    ) internal pure returns (bool) {
        bytes32 r;
        bytes32 s;
        uint8 v;

        (r, s) = abi.decode(signature, (bytes32, bytes32));
        v = uint8(signature[64]);

        (address signer, , ) = digest.tryRecover(v, r, s);

        if (signer == address(0)) revert InvalidSignature();
        if (signer != claimedSigner) revert InvalidSigner();

        return signer == claimedSigner;
    }

}

Frontend integration of Permit2.

The frontend integration of our SimplePermit2 contract using ethers.js. This is similar to how Uniswap Permit2-sdk is written with a little of abstraction. But we will be writing an integration code of our contract using ethers.js.

import { ethers } from 'ethers';

async function generatePermitSignature(
  ownerAddress: string,
  tokenAddress: string,
  amount: bigint,
  nonce: bigint,
  deadline: bigint,
  spenderAddress: string,
  permit2ContractAddress: string
) {
  // 1. Connect to the user's wallet
  const provider = new ethers.BrowserProvider(window.ethereum);
  const signer = await provider.getSigner();

  // 2. Prepare the domain and types for EIP-712 signature
  const domain = {
    name: "SimplePermit2",
    version: "1",
    chainId: await signer.getChainId(),
    verifyingContract: permit2ContractAddress
  };

  const types = {
    TokenPermissions: [
      { name: "token", type: "address" },
      { name: "amount", type: "uint256" }
    ],
    PermitTransferFrom: [
      { name: "permitted", type: "TokenPermissions" },
      { name: "spender", type: "address" },
      { name: "nonce", type: "uint256" },
      { name: "deadline", type: "uint256" }
    ]
  };

  // 3. Create the value object
  const value = {
    permitted: {
      token: tokenAddress,
      amount: amount.toString()
    },
    spender: spenderAddress,
    nonce: nonce.toString(),
    deadline: deadline.toString()
  };

  // 4. Request the signature from the user's wallet
  try {
    const signature = await signer.signTypedData(domain, types, value);
    
    // Split the signature into v, r, s components
    const sig = ethers.Signature.from(signature);
    return {
      v: sig.v,
      r: sig.r,
      s: sig.s,
      fullSignature: signature
    };
  } catch (error) {
    console.error("Error signing typed data:", error);
    throw error;
  }
}

Key Benefits of Permit2.

1. Gas Cost Savings:

   • Traditional ERC-20 token approvals require a separate transaction for each allowance, incurring gas fees. Permit2 eliminates the need for these redundant approval transactions, saving users gas costs.

2. Simplified User Experience:

   • Users can sign a single message off-chain instead of interacting with the blockchain twice (approval + transaction). This reduces complexity and enhances accessibility, especially for new users.

3. Reduced Approval Risks:

   • Traditional token approvals often involve granting large or unlimited allowances to smart contracts, exposing users to potential security risks. Permit2 enables users to set:

     • Custom Allowance Limits: Users can specify exact amounts to be approved.

     • Time-Limited Approvals: Permissions can expire automatically after a defined period, reducing exposure.

4. Cross-Platform Compatibility:

   • Permit2 is designed to work seamlessly across multiple decentralized applications (dApps) and protocols. This makes it a versatile solution for trading platforms, DeFi protocols, and wallet integrations.

5. Batch Operations:

   • Permit2 allows bulk approvals and transfers in a single transaction, optimizing workflows for advanced use cases such as portfolio management and multi-token swaps.

Conclusion

Permit2 is a significant step forward in enhancing the efficiency, security, and user experience of token approvals for decentralized trading. By reducing gas costs, simplifying workflows, and offering advanced features such as batch operations and time-limited allowances, Permit2 provides a powerful tool for DeFi protocols and traders alike.

For developers and platforms, integrating Permit2 into their systems can unlock better user experiences while optimizing transaction workflows. To integrate Permit2 into your solidity project, click here.