Slippage Protection Techniques for Polymarket AMM Trading Bots

Slippage protection techniques for Polymarket AMM trading bots are not optional plumbing — they are the difference between a strategy that survives and one that quietly bleeds edge on every fill. Polymarket's liquidity model is a hybrid: a Central Limit Order Book (CLOB) powered by the Gamma API sits on top of AMM-style automated liquidity, and the interaction between the two creates adverse-fill scenarios that catch most bot builders off guard.

How Polymarket's Hybrid Liquidity Creates Slippage Risk

When you send a market or aggressive limit order through the CLOB, the matching engine walks your order through the resting limit book first. On liquid markets — BTC up/down, major election calls — the top few levels are populated by active market makers and the spread is tight. On illiquid markets, the book may show a $0.06/0.07 best bid/offer but with only $50–$200 of depth at those prices before the next level jumps $0.04.

The AMM layer fills the gaps. Polymarket's AMM uses a constant-product curve seeded with initial liquidity, and it always quotes — even when the CLOB is thin. This means your order can hit CLOB liquidity for the first slice and then spill onto the AMM curve for the remainder. The AMM's effective price degrades as size increases: for a $1,000 order on a market with $5,000 total AMM liquidity, you should expect 1–4 cents of average-price impact beyond your target fill.

The practical danger is that your strategy prices around one liquidity source while filling against the other.

Snapshot Depth Before You Size

The most reliable protection starts before order submission. Pull a depth snapshot from the CLOB REST endpoint and compute available liquidity per price level:

import httpx

def get_depth_snapshot(market_id: str, side: str) -> list[dict]:
    url = f"https://clob.polymarket.com/book?token_id={market_id}"
    book = httpx.get(url, timeout=3).json()
    levels = book["asks"] if side == "buy" else book["bids"]
    return [{"price": float(l["price"]), "size": float(l["size"])} for l in levels]

def slippage_estimate(levels: list[dict], order_size: float) -> float:
    remaining = order_size
    total_cost = 0.0
    for level in sorted(levels, key=lambda x: x["price"]):
        fill = min(remaining, level["size"])
        total_cost += fill * level["price"]
        remaining -= fill
        if remaining <= 0:
            break
    if remaining > 0:
        # spills onto AMM — treat remaining as worst-case AMM fill
        total_cost += remaining * (levels[-1]["price"] + 0.05)
    avg_price = total_cost / order_size
    best_price = levels[0]["price"]
    return abs(avg_price - best_price)

This gives you a pre-flight slippage estimate in cents. If slippage_estimate() returns more than your configured tolerance — typically 1.5–3 cents on binary outcomes — you abort before touching the market.

Setting Dynamic Max-Slippage Parameters

Static slippage caps are wrong in both directions: too tight and you reject valid fills in thin conditions; too loose and you over-pay on every order. The right approach ties your tolerance to the current book state, which changes fast on Polymarket around news events.

Approach: volatility-adjusted tolerance

Track a rolling mean and standard deviation of the best-bid/offer mid across the last 30 seconds. Widen your slippage tolerance proportionally when mid-price variance is elevated:

import statistics

def dynamic_slippage_cap(
    mid_history: list[float],   # last 30s of mid-price readings
    base_cap: float = 0.020,    # 2 cents baseline
    vol_scalar: float = 2.5,
) -> float:
    if len(mid_history) < 5:
        return base_cap
    vol = statistics.stdev(mid_history)
    return min(base_cap + vol * vol_scalar, 0.060)  # hard ceiling at 6 cents

The vol_scalar of 2.5 means if mid-price has been moving at 1 cent standard deviation over the window, your cap widens to 4.5 cents — which is rational because the AMM curve has also shifted and you are not buying stale risk. The hard ceiling at 6 cents is non-negotiable; beyond that you are simply paying a bad price regardless of conditions.

Per-market calibration matters. A market at 5 cents (near certainty) has a very different dollar impact from 2 cents of slippage than a market trading at 50 cents. Express your tolerance as a fraction of the current mid, not an absolute:

def relative_slippage_cap(mid: float, max_fraction: float = 0.04) -> float:
    """4% of mid price as maximum slippage."""
    return mid * max_fraction

For our Polymarket market-making bot, we run both checks in sequence and take the tighter of the two.

Abort, Retry, or Reduce: The Order Decision Tree

Once you have a slippage estimate and a dynamic cap, the logic at submission time follows a strict decision tree:

• Estimate within cap → submit at limit price with max_slippage field set to your cap value in the CLOB API payload.
• Estimate exceeds cap, book depth is shallow → abort this cycle and re-evaluate after 500ms. Do not chase.
• Estimate exceeds cap, but reducing size would bring it within tolerance → compute the maximum size that fits within available book depth and submit that reduced order. Log the partial skip.
• Estimate still exceeds cap after max depth reduction → skip the market entirely this cycle. No order.

The key discipline here is the no-chase rule: if your abort fires, you do not immediately resubmit at a worse price. You wait for the next depth snapshot. This is what separates bots that survive Polymarket's periodic thin-book episodes from ones that get walked down the AMM curve on a bad day.

Detecting and Acting on Realized Slippage

Pre-flight checks cover the order-entry side, but fills can still come in worse than expected — particularly if another order hits the book in the same millisecond window. You need a fill-quality monitor running post-execution.

After a fill, compare the order's average fill price to the CLOB mid at the time of submission:

def realized_slippage(
    avg_fill_price: float,
    mid_at_submit: float,
    side: str,         # "buy" or "sell"
) -> float:
    if side == "buy":
        return avg_fill_price - mid_at_submit
    return mid_at_submit - avg_fill_price

If realized_slippage exceeds your dynamic cap on more than 15% of fills in a rolling 30-fill window, trigger a circuit break: suspend new orders on that market for 60 seconds and alert your monitoring channel. This pattern catches degraded market conditions before they compound.

For strategies that run across 50+ markets simultaneously — as we do in our cross-market arbitrage work — tracking fill quality per-market lets you rank-order markets by execution cost and deprioritize ones that consistently fill badly.

The AMM Curve Spill Calculation

When you know a portion of your order will spill onto the AMM, do not guess — compute it. Polymarket's AMM uses a standard x * y = k curve. You can reconstruct the effective AMM reserves from the on-chain pool contract or from the CLOB endpoint's synthetic levels.

For a buy order of size q with AMM reserves (x_token, y_usdc):

price_impact = q / (x_token + q)
effective_avg_price = y_usdc / x_token * (1 + price_impact / 2)

This is an approximation — good enough for a slippage estimate but not for exact accounting. In production, add 10% to whatever this formula returns as a cushion for fee rounding and mid-fill price movement.

The key insight is that AMM slippage scales with q / x_token. If you keep your per-order size below 2% of the AMM's token reserve, slippage from the curve stays under 1 cent on most markets. That is a practical position-sizing constraint worth embedding directly into your order-sizer.

Trade-offs and When to Accept More Slippage

Tight slippage caps reduce adverse fills but also reduce fill rates. On thin Polymarket markets, being too conservative means your strategy never accumulates a position. There are legitimate reasons to accept wider slippage:

• Time-sensitive events: if you are entering a position before a known resolution trigger (a game result, a Fed announcement), the cost of missing the fill outweighs the cost of 3–5 cents of extra slippage.
• Reversal strategies: when fading an overextended probability move, the expected mean-reversion profit is large enough to absorb wider fills. Our Polymarket reversal sniper uses a 5-cent cap rather than the standard 2-cent baseline for this reason.
• Large position accumulation: sometimes the edge in a market justifies a larger position than the book can absorb cleanly. In that case, split into tranches over multiple cycles rather than widening the cap — you preserve fill quality at the cost of slower accumulation.

The discipline is to adjust the tolerance for a strategic reason, not because the code is easier to write with a looser cap.

---

If you want slippage protection built into a Polymarket bot from the ground up — with proper depth-snapshot logic, dynamic caps and fill-quality monitoring — get in touch and we can spec the right architecture for your strategy.