Price Impact vs Slippage in Low Liquidity

A swap changes pool reserves. In a constant product pool, the simplified invariant is x * y = k. As a trader adds one asset and removes the other, the marginal price moves continuously. Price impact can be approximated as (execution price - pre trade mid price) / pre trade mid price, expressed as a percentage, with the sign interpreted according to trade direction. Interfaces may use slightly different reference prices and include or separate fees.

Suppose a pool contains 10,000 LIME and 10,000 USDC, initially quoting 1 USDC per LIME. Ignoring fees, a 1,000 USDC purchase raises the USDC reserve to 11,000. The LIME reserve must become 100,000,000 / 11,000 = 9,090.91. The buyer receives about 909.09 LIME at an average price of 1.10 USDC. The order's average execution is 10 percent above the initial spot quote, while the final marginal price is about 1.21 USDC.

A quote is computed from a particular blockchain state. Before the transaction executes, other swaps can alter reserves, the route can change, gas conditions can delay inclusion, or a concentrated position can cross a tick. Slippage is the difference between the quoted outcome and the actual execution outcome. It may be favorable or unfavorable, although user interfaces focus mainly on limiting unfavorable movement.

If the interface quotes 909.09 LIME but another purchase executes first, the same input may now return only 880 LIME. That difference is slippage relative to the quote. The original quote already contained the user's modeled price impact. Combining the two concepts can lead users to raise tolerance when the real issue is that the order is too large for the pool.

For an exact input swap, a common protection is minimum amount out. If the quote is 909.09 LIME and tolerance is 1 percent, the minimum is approximately 909.09 * (1 - 0.01) = 900 LIME. If execution would return less, the transaction should revert rather than accept that output. For an exact output swap, the corresponding protection is a maximum input amount.

Tolerance does not add liquidity, reduce the curve's price impact, or guarantee execution. A narrow tolerance may cause a transaction to fail in a volatile or rapidly changing pool. A wide tolerance permits a worse result and can increase exposure to adverse ordering or sandwich behavior. The appropriate setting depends on the specific route and transaction constraints, not a universal percentage.

Repeat the LIME purchase in a pool with 1,000,000 LIME and 1,000,000 USDC. Ignoring fees, adding 1,000 USDC returns roughly 999 LIME, much closer to the initial 1 USDC quote. The input is only 0.1 percent of the quote reserve rather than 10 percent. Deeper reserves make the curve flatter for the same order, so both expected impact and sensitivity to nearby trades are lower.

Visible total value is not always the relevant denominator. In Uniswap v3, only positions whose ranges include the current price provide active liquidity. Crossing a range boundary can sharply change depth. Routes can also split an order across pools, and Raydium or Uniswap interfaces may find a better aggregate outcome than any single pool. Transfer fee tokens can make standard estimates inaccurate because the pool receives less than the submitted amount.

A quote is a simulation, not a guarantee. Node latency, fee changes, route updates, token restrictions, and block ordering can affect execution. Price impact percentages from two interfaces may not be directly comparable if one uses the pool spot price and another uses an external reference. Failed transactions can still consume network fees, depending on the chain.

Review the minimum received or maximum spent field, not only the tolerance label. Compare smaller order sizes, inspect active pool depth, verify token behavior, and consider whether the route uses trustworthy contracts. GoPlus can surface selected token and approval risks, while official Uniswap and Raydium documentation explains protocol mechanics. These tools support analysis, but they do not eliminate execution risk or provide a guaranteed result.