$npx -y skills add agiprolabs/claude-trading-skills --skill slippage-modelingExecution cost estimation, slippage curve modeling, and optimal trade sizing based on AMM liquidity depth
| 1 | # Slippage Modeling |
| 2 | |
| 3 | Estimate execution costs, model slippage curves from AMM mechanics and empirical quotes, and determine optimal trade sizes that keep costs within acceptable thresholds. |
| 4 | |
| 5 | ## What Is Slippage? |
| 6 | |
| 7 | Slippage is the difference between the **expected price** at the time you decide to trade and the **actual execution price** you receive. On decentralized exchanges, slippage is deterministic and measurable — unlike CEX slippage, which depends on hidden order book dynamics. |
| 8 | |
| 9 | **Example**: You expect to buy a token at 0.001 SOL. Your trade executes at 0.00105 SOL. That 5% difference is slippage — it directly reduces your profit and increases your break-even threshold. |
| 10 | |
| 11 | ## Sources of Slippage |
| 12 | |
| 13 | ### 1. AMM Price Impact (Primary Source) |
| 14 | |
| 15 | Automated market makers use bonding curves that move price as liquidity is consumed. On a constant-product AMM (`x * y = k`): |
| 16 | |
| 17 | ``` |
| 18 | price_impact = Δx / (x + Δx) |
| 19 | ``` |
| 20 | |
| 21 | Where `x` is the reserve of the input token and `Δx` is your trade size. A 1 SOL trade against a pool with 100 SOL reserves produces ~1% price impact. Against 10 SOL reserves, it produces ~10%. |
| 22 | |
| 23 | See `references/slippage_math.md` for full derivations and CLMM adjustments. |
| 24 | |
| 25 | ### 2. DEX Fees |
| 26 | |
| 27 | Every swap incurs a fee taken from the trade: |
| 28 | |
| 29 | | DEX | Fee | Notes | |
| 30 | |----------|-----------|--------------------------------| |
| 31 | | Raydium | 0.25% | Standard AMM pools | |
| 32 | | Orca | 0.30% | Whirlpool concentrated pools | |
| 33 | | Meteora | 0.1–2.0% | Dynamic fees based on volatility| |
| 34 | | PumpFun | 1.0% | Bonding curve phase | |
| 35 | |
| 36 | ### 3. Priority Fees |
| 37 | |
| 38 | Solana validators prioritize transactions with higher compute unit prices. During congestion or for time-sensitive trades: |
| 39 | - Normal: 0.0001 SOL (negligible) |
| 40 | - Competitive: 0.001–0.01 SOL |
| 41 | - High congestion: 0.01–0.1 SOL |
| 42 | |
| 43 | ### 4. MEV (Sandwich Attacks) |
| 44 | |
| 45 | Searchers detect pending swaps and sandwich them — buying before your trade (raising the price) and selling after (capturing the difference). MEV cost depends on: |
| 46 | - Trade size (larger = more attractive target) |
| 47 | - Token liquidity (thin pools = easier to manipulate) |
| 48 | - Slippage tolerance setting (higher tolerance = more extractable) |
| 49 | |
| 50 | Typical MEV cost: 0–200 bps on vulnerable trades. |
| 51 | |
| 52 | ### 5. Stale Quotes |
| 53 | |
| 54 | Between receiving a quote and landing the transaction on-chain (0.4–2 seconds on Solana), the price may move. Volatile tokens can shift 50–500 bps in that window. |
| 55 | |
| 56 | ## Constant-Product Slippage Formula |
| 57 | |
| 58 | For a pool with reserves `(x, y)` and invariant `k = x * y`: |
| 59 | |
| 60 | **Buying tokens with SOL** (input Δx SOL): |
| 61 | ``` |
| 62 | tokens_received = y * Δx / (x + Δx) |
| 63 | effective_price = Δx / tokens_received = (x + Δx) / y |
| 64 | spot_price = x / y |
| 65 | price_impact = effective_price / spot_price - 1 = Δx / (x + Δx) |
| 66 | ``` |
| 67 | |
| 68 | **Selling tokens for SOL** (input Δy tokens): |
| 69 | ``` |
| 70 | sol_received = x * Δy / (y + Δy) |
| 71 | effective_price = sol_received / Δy = x / (y + Δy) |
| 72 | spot_price = x / y |
| 73 | price_impact = 1 - effective_price / spot_price = Δy / (y + Δy) |
| 74 | ``` |
| 75 | |
| 76 | **Key insight**: Slippage scales with `trade_size / (reserves + trade_size)`. This is approximately linear for small trades and accelerates sharply as trade size approaches reserve size. |
| 77 | |
| 78 | ### Quick Reference Table |
| 79 | |
| 80 | | Trade / Reserve Ratio | Approximate Slippage | |
| 81 | |----------------------|---------------------| |
| 82 | | 0.1% | 0.1% (1 bp) | |
| 83 | | 1% | 1.0% (100 bps) | |
| 84 | | 5% | 4.8% (476 bps) | |
| 85 | | 10% | 9.1% (909 bps) | |
| 86 | | 25% | 20% (2000 bps) | |
| 87 | | 50% | 33% (3333 bps) | |
| 88 | |
| 89 | ## CLMM Slippage |
| 90 | |
| 91 | Concentrated Liquidity Market Makers (Orca Whirlpools, Meteora DLMM) concentrate liquidity in specific price ranges: |
| 92 | |
| 93 | - Within the active range: slippage is **lower** than constant-product by a concentration factor |
| 94 | - Crossing tick boundaries: additional slippage as the next tick's liquidity may be sparse |
| 95 | - Approximation: `clmm_slippage ≈ cp_slippage / concentration_factor` |
| 96 | |
| 97 | Typical concentration factors: 5–50x for well-managed positions. |
| 98 | |
| 99 | ## Empirical Slippage Measurement |
| 100 | |
| 101 | Theoretical formulas assume single-pool routing. In practice, Jupiter aggregates across multiple pools and routes. **Empirical measurement** is more accurate: |
| 102 | |
| 103 | 1. Query Jupiter `/quote` at multiple trade sizes (0.01, 0.1, 1, 5, 10, 50 SOL) |
| 104 | 2. Record output amount and effective price at each size |
| 105 | 3. Compute slippage in bps relative to smallest trade (proxy for spot) |
| 106 | 4. Fit a power-law model: `slippage_bps = a * trade_size^b` |
| 107 | |
| 108 | This captures real routing behavior, multi-pool splitting, and available liquidity. |
| 109 | |
| 110 | See `scripts/slippage_curve.py` for the full implementation. |
| 111 | |
| 112 | ## Total Execution Cost Model |
| 113 | |
| 114 | ``` |
| 115 | total_cost_bps = price_impact_bps + fee_bps + priority_fee_bps + mev_risk_bps |
| 116 | total_cost_sol = trade_size_sol * total_cost_bps / 10_000 |
| 117 | `` |