// EXECUTION & FEES

What is smart order routing? Applied to prediction markets

2026-07-16 · Mithril

In US equities, nobody manually decides whether their Apple order goes to Nasdaq, NYSE, or one of a dozen other venues. A smart order router (SOR) looks at every venue's quote, accounts for fees and rebates, and sends the order — or slices of it — wherever the all-in price is best. The idea is fifty years downstream of fragmented markets and legally reinforced by best-execution rules.

Prediction markets in 2026 are fragmented in exactly the same way — the same event trades on Kalshi and Polymarket at prices that rarely agree — but almost everyone routes by hand, or not at all. This post explains what SOR means, what changes when you apply it to two prediction-market venues instead of sixteen equity exchanges, and where the hard parts actually are.

SOR in one paragraph

A smart order router takes an order ("buy 1,000 YES in market X, limit 45¢") and answers three questions before anything hits an exchange:

1. Which venues list this instrument?
2. What is the net cost of filling at each venue, at this size, after fees?
3. Is the best answer one venue, or a split?

Then it executes, monitors the fills, and re-routes the unfilled remainder as books change. The core insight is that the displayed price is an input, not the answer — fees, depth, and venue mechanics all move the net.

What's different in prediction markets

The instrument-matching problem comes first

Equity SORs get instrument identity for free: AAPL is AAPL on every exchange. Prediction markets have no shared identifier — Kalshi has tickers like FED-26SEP-T4.00, Polymarket has condition IDs like 0x26d06d…, and deciding that two contracts settle on the same real-world event with the same resolution criteria is genuinely hard. Two markets on "the Fed cuts in September" can differ on the data source, the deadline, or edge cases in resolution. Routing across venues is only safe once that mapping exists and has been checked — the problem unified market IDs exist to solve.

The fee comparison is asymmetric

Equity venue fees are flat per-share maker/taker rates. Here, one venue (Kalshi) charges takers a price-dependent formula fee — 0.07 × contracts × price × (1−price), rounded up — while the other (Polymarket) charges no exchange trading fee on most markets but embeds its costs in spread and depth. So the router's cost model is not "add 30 mils"; it is: walk each venue's order book to your size, compute the average fill price, add that venue's fees, compare. The worked numbers — including the cases where the displayed-cheaper venue loses — are in Kalshi vs Polymarket fees.

Two venues, but thin books

With sixteen equity venues, SOR is mostly venue selection. With two prediction-market venues and books measured in hundreds of contracts, SOR is mostly size allocation: the best answer for a 2,000-contract order is frequently "1,200 on the venue with the better touch, 800 on the other" — because sweeping either book alone would cost more in slippage than the cross-venue price difference. A useful router here is inseparable from an order-working engine: it splits across venues and across time, posting and pacing rather than sweeping. See Slippage in thin prediction markets.

Settlement and capital aren't fungible

An equity SOR settles everything to the same account. Here, Kalshi fills settle in USD at a CFTC-regulated exchange; Polymarket fills settle in USDC on Polygon via a CLOB with wallet-signed orders. A router can only use the liquidity your capital can reach — if all your USDC is on Polygon and Kalshi is net-cheaper, the "optimal" route is unavailable until you move money. Real routers must be balance-aware, and sustained one-sided routing implies periodic rebalancing with its own costs.

The routing decision, concretely

For a marketable buy of size S:

for each venue v in {kalshi, polymarket}:
    walk v's ask book to depth S → avg_price(v, S)
    net(v, S) = avg_price(v, S) + fees(v, S, price)

for each split (a, S−a):
    net_split = net(kalshi, a)·a/S + net(polymarket, S−a)·(S−a)/S

execute argmin over {kalshi-only, polymarket-only, best split}
subject to: limit price, balances, and risk caps

Everything hard hides inside fees() (formula fee + round-up on one side; gas assumptions on the other), in stale-quote handling (the book you evaluated is milliseconds old), and in what happens when one leg of a split fills and the other doesn't.

Single-venue markets: SOR still earns its keep

Plenty of markets exist on only one venue — Kalshi's economic-data ladders, Polymarket's long-tail markets. Routing there is trivial, but the router's machinery still matters: the same code that walks books to compute net prices is what enforces slippage caps, works size passively instead of sweeping, and benchmarks the fill afterward. Venue selection is one output of an execution engine, not the whole point.

Trust, but verify

An SOR's claim — "this was the best available net price" — is checkable. Record the arrival state of both books, the routing decision, the fills, and the itemized fees, and anyone can audit whether the routing helped. That artifact is an execution receipt, and it is the subject of Execution receipts: what best execution means in prediction markets.

This is the design Mithril ships: one API over Kalshi and Polymarket with unified mkt_ IDs (solving the matching problem), fee-aware routing that walks both books at your size, order-working for thin markets, and a receipt on every fill so the routing decision is auditable rather than asserted. Free during beta, with docs at api.trymithril.com.

Venue mechanics and fee schedules change. Details above reflect public documentation as of July 2026 — always confirm against the venues' own docs before trading real money.