Slippage in AMM
mollen OGLet’s talk about slippage.
If you’ve ever traded on Uniswap or any AMM and thought:
“Wait… why did I get less tokens than I expected?”
Congrats. You just got slapped by slippage.
What the heck is Slippage?
In AMMs, prices aren’t fixed. They’re determined by this cute little math rule:
x * y = k
Every time someone trades, they mess with the pool’s balance, which nudges the price around. That’s slippage.
Quick example:
Pool has 10 ETH and 20,000 USDT (so 1 ETH = 2,000 USDT).
You toss in 1,000 USDT to buy ETH.
After fees and the pool doing its magic math, you walk out with ~0.99 ETH.
So instead of paying 2,000 per ETH, you actually paid ~2,009.95.
That little difference (0.5%)? That’s slippage.
And trust me, it gets uglier the bigger your trade or the smaller the pool.
How Do You Fight Back Against Slippage?
More Liquidity = Less Pain
Larger pools have more tokens, reducing the price impact of trades. For example, a pool with 100 ETH and 200,000 USDT will experience less slippage than one with 10 ETH and 20,000 USDT for the same trade size.
Protocol Solution: Incentivize liquidity providers (LPs) with higher fees or rewards (e.g., Uniswap’s fee tiers or Curve’s governance token rewards).
Trader Solution: Choose pools with higher liquidity for the desired pair.
Don’t YOLO Huge Trades
Smaller trades cause smaller changes to the pool’s ratio, reducing slippage.
Trader Solution: Split large trades into smaller chunks and execute them over time or across multiple pools.
Code-Level Slippage Protection:
- Add a minimum output check in the AMM contract to ensure the trader receives at least the expected amount, reverting the transaction if slippage is too high.
function swapAforB(uint256 amountAIn, uint256 minAmountBOut) external returns (uint256 amountBOut) {
require(amountAIn > 0, "Invalid input amount");
require(reserveA > 0 && reserveB > 0, "No liquidity");
uint256 amountAInWithFee = (amountAIn * (1000 - FEE)) / 1000;
amountBOut = (reserveB * amountAInWithFee) / (reserveA + amountAInWithFee);
require(amountBOut >= minAmountBOut, "Excessive slippage"); // Slippage protection
tokenA.transferFrom(msg.sender, address(this), amountAIn);
tokenB.transfer(msg.sender, amountBOut);
reserveA += amountAIn;
reserveB -= amountBOut;
require(reserveA * reserveB >= reserveA * reserveB, "Invariant violation");
return amountBOut;
}
Concentrated Liquidity (Uniswap V3 vibes 🌊)
Imagine if LPs could say:
“Yo, I only want my liquidity to work between $1,900 and $2,100 ETH. Don’t bother me if ETH goes to $10 or $10,000.”
That’s concentrated liquidity. LPs pile their funds in a tight range, so trades in that range barely move the price.
Protocol fix: Build Uniswap V3-style range-based liquidity.
Trader hack: Trade in pools where liquidity is stacked in the range you care about.
It’s more complex, yeah, but it’s basically capital efficiency on steroids.
StableSwap Curves (Curve Finance’s secret sauce 🥤)
Normal AMM math (x * y = k) is fine until you’re dealing with stablecoins.
Nobody wants USDT at 0.97 or 1.05. You want that sweet 1:1.
Curve invented a new curve shape that keeps stables glued together with ultra-low slippage.
Protocol fix: Deploy specialized curves for stables/pegged assets.
Trader hack: Use Curve when swapping stables. Always.
Dynamic Fees (Balancers in the wild ⚖️)
Flat fees are cute. But what if the pool could crank fees up during big swings or whale trades?
This discourages trades that would blow the pool’s ratio.
Protocol fix: Adjustable/dynamic fees baked into the math.
Trader hack: Trade at calm times → pay less.
Oracle Checks (Because sometimes AMMs get drunk 🍻)
AMMs can drift far from the “real” price if arbitrageurs aren’t around fast enough.
Solution? Cross-check with an oracle like Chainlink. If the AMM price is way off → reject the trade.
- Protocol fix: Add oracle sanity checks to contracts.
Other Problems Slippage Brings to the Party
Slippage isn’t just annoying — it invites some serious monsters into the room:
🥪 Front-Running & MEV
Bots watch the mempool, see your juicy trade, and jump ahead of you to profit. Classic sandwich attack.
Impact: You get wrecked, LPs miss fees.
Fix: commit-reveal, batch auctions, KeeperDAO-style protection, or simple slippage limits.
📉 Impermanent Loss Gets Worse
Big slippage → arbitrage kicks in → LPs end up holding the worse asset.
- Fix: concentrated liquidity or stable curves to minimize swings.
😤 Bad UX
Nobody likes seeing their trade fail because slippage protection kicked in. Or worse, watching their bag shrink.
- Fix: warn users clearly, show suggested trade sizes, or auto-route through aggregators like 1inch.
🎭 Price Manipulation
Low-liquidity pools can be gamed. Attackers push the price around to exploit oracles or mess with downstream protocols.
- Fix: use TWAP oracles, cap trade sizes, keep pools liquid.
⛽️ Gas Gets Burned
Failed trades (thanks to slippage protection) still eat gas. It’s like paying for a taxi ride that never leaves the curb.
- Fix: optimize contracts, add off-chain estimation with SDKs.
🌊 Liquidity Fragmentation
Uniswap V3 created a buffet of price ranges, but now liquidity is scattered everywhere. If you land in a thin range, slippage spikes.
- Fix: nudging LPs into active ranges or letting aggregators stitch together the deepest routes.
The point: slippage is DeFi’s gravity. You can’t escape it, but you can engineer around it — whether that’s new math (Curve), smarter LP design (Uniswap V3), or better UX + protection.
Subscribe to my newsletter
Read articles from mollen OG directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by