API + MCP live · talk to us

// EXECUTION & FEES

Execution receipts: what best execution means in prediction markets

2026-07-16 · Mithril

When a broker in traditional markets tells you they got you a good fill, you don't have to take their word for it. Decades of regulation and practice — best-execution obligations, transaction cost analysis (TCA), standardized benchmarks — turned "good fill" from a claim into a measurement. Prediction markets have none of that culture yet. Fills happen, prices print, and nobody can tell you whether their execution is good, because nobody is measuring it against anything.

This post imports the useful parts: what best execution actually means, which benchmarks transfer to Kalshi and Polymarket, and what a per-fill execution receipt should contain so that execution quality becomes an auditable number instead of a vibe.

Best execution, minus the regulation

In equities, brokers have a formal duty to seek the most favorable terms reasonably available — considering price, cost, speed, and likelihood of execution — and institutions run TCA on every order to hold their brokers to it. Strip away the legal apparatus and the core is a simple discipline:

  1. Fix a benchmark before (or at) the moment the order arrives.
  2. Record the fill — every partial, every price, every fee.
  3. Compute the difference, and attribute it: spread, impact, fees, timing.

Nothing about that requires a regulator. It requires data you already have access to — both venues publish full order books via API — and the discipline to snapshot it at the right moment.

Benchmarks that make sense here

Arrival mid

The standard reference point: the midpoint between best bid and best ask at the moment your order arrived. If the book was 41¢ bid / 43¢ offer when you decided to buy, arrival mid is 42¢. Fill at an average of 43.4¢ with 1.7¢ of fees, and your implementation shortfall is 3.1¢ per contract — spread (1¢) + impact (0.4¢) + fees (1.7¢), each attributable.

Arrival mid is honest because it is fixed before execution and can't be gamed by the executor. Two prediction-market caveats: in very wide books the mid is a weak estimate of fair value (a 30¢/50¢ book has a "mid" of 40¢ that nobody would trade at), and one-sided books around news make it undefined. A receipt should record the raw bid and ask alongside the mid so you can judge how much to trust it.

The naive-sweep benchmark

For evaluating a router or order-working engine, arrival mid is not enough — you want to know what would have happened without it. The right counterfactual is the naive sweep: take the arrival book snapshot, simulate your full size as one marketable order at your default venue, add that venue's fees, and record the resulting average net price. Then compare the actual worked/routed fill against it.

This is the fair test of execution machinery because it is exactly what you would have done by hand. If the router split across venues and beat the naive sweep net of all fees, the difference is genuine, attributable savings. If it didn't — for instance, because pacing the order let the price drift away — the receipt should show that too. A benchmark that can only ever flatter the executor is marketing, not measurement.

Fee itemization

Because Kalshi charges an explicit formula-based taker fee while Polymarket's costs are implicit in the book (details: Kalshi fees explained, Polymarket fees and gas explained), any cross-venue comparison that isn't itemized is meaningless. The receipt must show, per venue: displayed price, average fill, contracts, exchange fee applied (with the actual rounding), and gas assumptions if relevant — so that the net-vs-net comparison in Kalshi vs Polymarket fees is reproducible from the receipt alone.

Anatomy of an execution receipt

A minimal, auditable receipt for a filled order:

json
{
  "order_id": "ord_01j…",
  "market": "mkt_fed_cut_sep26",
  "side": "buy_yes",
  "requested": 1000,
  "filled": 1000,
  "arrival": {
    "ts": "2026-07-16T14:02:11Z",
    "kalshi":     { "bid": 41, "ask": 43, "mid": 42.0 },
    "polymarket": { "bid": 0.415, "ask": 0.435, "mid": 0.425 }
  },
  "benchmark": {
    "arrival_mid": 42.25,
    "naive_sweep_net": 44.1
  },
  "fills": [
    { "venue": "kalshi",     "qty": 600, "avg_price": 43.0, "fee": 10.30 },
    { "venue": "polymarket", "qty": 400, "avg_price": 0.432, "fee": 0.00 }
  ],
  "net_avg_price": 43.36,
  "vs_arrival_mid": -1.11,
  "vs_naive_sweep": +0.74
}

(Illustrative structure, not real market data.) The two bottom-line numbers answer the two different questions: what did execution cost me relative to fair value at arrival? and did the machinery beat what I'd have done naively? Note they can disagree — an order can underperform arrival mid (markets moved) while still beating the naive sweep (the machinery helped). Both facts are worth knowing; conflating them is how execution quality gets misrepresented.

Why receipts beat claims

Any execution vendor — in any asset class — has an incentive to tell you they saved you money. The only durable defense is that the evidence arrives with every fill and is checkable against public data: the arrival book snapshot can be compared with the venues' own market-data feeds, the fee math can be recomputed from the venues' published schedules, and the counterfactual is stated explicitly enough to re-run. Aggregate savings claims ("traders save X%") tell you about someone else's order flow, or about nothing; a per-fill receipt tells you about your orders.

This is the design principle behind Mithril's execution receipts: every fill routed through the API comes back with the arrival snapshot, the naive-sweep benchmark, the routing decision, and the itemized fees. When routing beats the benchmark, the receipt shows by how much; when it doesn't, it shows that instead. Your number, not our claim. It is free during beta.

Start measuring, even without any of this

If you trade programmatically today, you can begin with twenty lines of code: snapshot the book before each order, log fills and fees, compute shortfall vs arrival mid weekly. Most traders who do this for the first time discover that execution — spread, slippage, and fees together — costs them several times what they assumed, and that discovery changes behavior more than any blog post will.

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.

One API + MCP for Kalshi and Polymarket

Fee-aware routing, unified market IDs, and hard server-side risk limits — live today, free during beta.