// EXECUTION & FEES

Slippage in thin prediction markets and how to avoid it

2026-07-16 · Mithril

The most expensive thing most prediction-market traders do is send a market order for more contracts than the top of the book holds. No fee schedule on either venue comes close to what a careless sweep of a thin book costs — and unlike fees, this cost never appears on a statement. It just shows up as a worse average price than you thought you got.

This post is about slippage: what it is, why prediction-market books make it severe, and the four standard tools for containing it.

What slippage is, precisely

Slippage is the difference between the price you decided to trade at and the average price you actually filled at. For a marketable order it has two parts:

• Sweeping levels: your size exceeds the best quote, so you fill each successively worse level of the order book.
• Price movement: the book changed between your decision and your fill.

Consider a Kalshi book offering 300 contracts at 44¢, 500 at 45¢, 700 at 46¢. A market buy of 1,000:

300 @ 44¢ + 500 @ 45¢ + 200 @ 46¢
average fill = 44.9¢   →   0.9¢ of slippage vs the touch

That 0.9¢ per contract is before Kalshi's taker fee (~1.7¢ near these prices) and before counting the half-spread you crossed. On a contract that pays at most $1, giving up 2–3¢ to execution on entry and again on exit is a strategy-killing tax.

Why prediction markets are especially thin

• Liquidity is event-shaped. Depth concentrates in a handful of headline markets; the long tail trades by appointment. The same venue can have a deep book on one election market and 50 contracts at the touch on the next tab over.
• Liquidity is time-shaped. Books deepen near catalysts (data releases, debates, deadlines) and evaporate overnight. The size that cost 0.5¢ to execute at 2pm can cost 4¢ at 2am.
• Books recover slowly. In equities, swept liquidity refreshes in milliseconds. Here, the quotes you swept may take minutes to return — your own second slice can be trading against the crater your first slice made.

First measure it: pull the book (both venues publish full order books via API), simulate your size against it, and compute the average fill. If you can't tolerate the number, don't send the market order.

The four tools

1. Slice and pace

Break the parent order into child orders sized to the book — a common rule of thumb is to keep each child within a fraction of the displayed top-level depth — and space them out so the book can refill. This is the thin-market version of TWAP/participation algos. The trade-offs are time risk (the price can run away while you're being patient) and, on Kalshi, the round-up-to-a-cent fee rule, which charges each child order separately — see Kalshi fees explained.

2. Post passively

Instead of taking 45¢ offers, bid 43¢ and wait. You earn the spread rather than paying it, and on Kalshi you generally avoid the taker fee entirely on most markets — a double saving. The costs are the classic maker-taker trade-offs: you may never fill, and the fills you do get are adversely selected (you get filled fastest when news moves the market through your price). Passive execution suits views with slow decay; it is wrong for trading a catalyst in the next ten minutes. If you find yourself doing a lot of this, you are drifting into market making — which is fine, but be deliberate about it.

3. Use both venues

The same event often trades on Kalshi and Polymarket, and their books are independent liquidity pools. Splitting 1,000 contracts as 600/400 across two books frequently beats sweeping either alone — the whole argument for smart order routing. The comparison must be net of fees, since the venues charge so differently: see Kalshi vs Polymarket fees.

4. Hard slippage caps

Whatever else you do, bound the damage mechanically: use limit orders (a marketable limit at "touch + 1¢" caps your sweep depth), and if your stack supports it, a per-order slippage cap that rejects any fill worse than a set distance from the arrival price. The failure mode you are buying insurance against is not the typical order — it is the fat-fingered size, the stale-data retry loop, or the bot that keeps firing into an evaporating book. Caps convert "unbounded loss" into "missed trade," which is nearly always the right trade-off for automated systems.

A decision rule

For a marketable order of size S:

1. Simulate S against the current book(s). If simulated slippage is within your tolerance — send it, capped with a limit price.
2. If not, and your edge decays slowly — slice, pace, and post.
3. If not, and your edge decays fast — take what the book gives you within your cap and let the rest go. Paying 5¢ of slippage to capture 3¢ of edge is not a trade; it is a donation.

Automating it

Everything above is mechanical, which means it belongs in software rather than in discipline. Mithril's execution engine does this server-side: orders are checked against both venues' books, worked in slices when the book is thin, split across venues when that nets better, and rejected by a hard slippage bound you set per key — with the resulting fills itemized on an execution receipt so you can see what execution actually cost. It is free during beta.

Order book behavior and venue mechanics change. Details above reflect public documentation as of July 2026 — always confirm against the venues' own docs before trading real money.