Key takeaways
- A prediction market arbitrage scanner must detect cross-venue price gaps, normalize equivalent contracts, and alert with fee-adjusted edge, not raw price differences.
- Kalshi’s per-contract fee can erase most of a 3% gross gap, so every signal should be net of taker fees, slippage, and withdrawal costs.
- Cross-venue scans between sportsbooks and prediction markets like Polymarket and Kalshi capture the opportunity set that single-lane scanners miss.
- Polling every 30-60 seconds is usually enough for prediction market dislocations, while sportsbook arbs need 1-5 second polls or streaming.
- Build your own scanner when your venue is uncovered, the tool’s fee model is wrong, or you need raw API access; otherwise buy and be running in an afternoon.
A good prediction market arbitrage scanner watches Kalshi and Polymarket order books plus sportsbook odds, flags cross-venue price gaps, and nets those gaps against taker fees and slippage so you only see real edge. This guide ranks off-the-shelf options on fees, latency, and coverage, then shows how to build your own scanner on an odds API when they fall short.
What does a prediction market arbitrage scanner actually do?
A prediction market arbitrage scanner polls multiple venues, normalizes equivalent outcomes into a common schema, detects cross-venue price mismatches, and surfaces the fee-adjusted edge before it decays. That is the whole job. Everything else is implementation detail.
The three jobs: detect, normalize, alert
Detect means polling every venue fast enough to catch a mismatch while both legs are still fillable. Normalize means mapping “Yes on X wins” on one venue to the identical contract elsewhere, including resolution criteria. Alert means pushing the opportunity with enough metadata (fees, spread, timestamp) that you can judge it instantly.
Fees are not optional math. Polymarket charges taker fees on certain markets, per its fee documentation, so a 3-cent mismatch can be a 1-cent edge after costs. Any scanner worth running, including ours (see how we built it), computes edge net of fees and latency, not raw price gaps.
Which markets and venues do the best arbitrage scanners cover?
Coverage decides whether a scanner finds anything. Most tools sit in one lane: sportsbook-only scanners like The Odds API or SportsGameOdds watch books, while prediction-market tools watch Polymarket and Kalshi. The profitable gap is cross-venue.
Polymarket and Kalshi equivalents
The core scan is a YES on Polymarket against NO on Kalshi for the same event, adjusted for each venue’s fee schedule and contract mechanics. You need a scanner that normalizes event definitions across both venues, since identical questions are often worded differently and settlement rules can diverge.
Sportsbook-to-prediction-market arb
The bigger edge: a moneyline at an outlier book priced above the implied probability of the matching Polymarket or Kalshi contract. Most scanners miss it because sports odds and prediction market order books live in different data formats. A feed that returns both, with freshness metadata so stale sportsbook lines don’t fake an arb, is the prerequisite. If your current API covers only one side, you’re scanning half the opportunity set. If you need both sides in one request, tell us what you’re building.
| Venue pair | What you scan | Main friction |
|---|---|---|
| Polymarket vs Kalshi | YES/NO on same event | Fee and wording normalization |
| Sportsbook vs Polymarket | Moneyline vs contract price | Format mismatch, stale lines |
| Sportsbook vs sportsbook | Outlier books vs consensus | Latency, credit burn |
How do fees and slippage change whether an arbitrage is real?
A 3% headline gap between two venues is not a 3% return. Prediction markets and sportsbooks each take a cut, and the cut lands on different parts of the trade depending on where you fill.
Worked example: suppose you buy Yes on Polymarket at $0.97 and No on Kalshi at $0.05 for a matched $1,000 position. Polymarket currently charges no taker fee on most markets, but Kalshi’s fee schedule applies a per-contract trading fee on the buy side, calculated from contract price and a fee multiplier listed in Kalshi’s fee schedule documentation. On a $0.05 fill, that fee is small but non-zero; on fills near $0.50, it runs roughly 3.5-7% of notional and erases most headline gaps by itself. Run the arithmetic before you trust any signal: at $0.97 plus $0.05 you are paying $1.02 per matched pair, so the gross edge is negative before fees even enter. That is the point most scanners miss: the raw price gap and the fee-adjusted edge are different numbers, and only the second one pays.
That paragraph is the whole discipline: fee-adjusted edge = (1 - sum of prices) - taker fees on both legs - expected spread cost - withdrawal costs. A 3% gross gap with a 5-cent Kalshi fill and a 1% withdrawal haircut is roughly break-even. Run this formula on every signal your scanner emits, and log the fee inputs per venue so you can audit which “arbs” were actually dead on arrival. Sportsbook legs add vig instead: a no-vig consensus line tells you the fair price, and an outlier book beyond that fair price is your leg, but only after the book’s own margin on the other side of the book.
Slippage is the second killer. Order-book depth on prediction markets is thin away from the top of book, so a $1,000 fill can walk three price levels and consume your entire edge. Size your arb to the depth at your limit price, not to the displayed best quote. If you’re testing scanner economics against sportsbook lines too, PingOdds returns freshness metadata with every response (pricing), so a stale quote never masquerades as a live arb.
How fast does a scanner need to be for prediction market arb?
Latency budgets depend on the strategy. Cross-venue sportsbook arbs on liquid markets die in seconds, so you want a 1-5 second poll or a stream. Prediction market dislocations on Kalshi or Polymarket can persist for minutes, which means a 30-60 second poll is often enough for spot checks but not for catching steam moves before they close.
Polling vs streaming tradeoffs
Polling is cheaper and simpler: one request returns every book’s line, and you control the credit burn. Streaming costs more to operate but pushes line movement to you the moment it happens. A practical middle ground is polling on longshot props where arbs linger, and a WebSocket for the main lines. PingOdds supports both, and the streaming setup is documented in full.
Detecting stale quotes
The killer failure mode is cached data faking an arb: you see a +EV spread, bet it, and the line moved 30 seconds ago. Freshness metadata per response, with a timestamp per book, lets you discard quotes past your staleness threshold instead of acting on ghosts.
How do prediction market scanners differ from options or sportsbook arbitrage scanners?
Settlement mechanics drive the biggest difference. Sportsbook positions settle against a bookmaker’s ruling, options settle against an exchange’s clearinghouse, and prediction markets settle against a binary event, so a scanner must verify that both legs of a trade resolve on the same criteria, not just that prices sum below 100%.
Fee structures diverge too. Sportsbook arb means balancing stake sizes across books with no explicit trading fee, while prediction markets charge per-contract fees that can erase thin spreads, so your scanner should model fees the same way it models latency.
Data availability shapes design most. Odds APIs like The Odds API meter access in credits, and PingOdds exposes per-response freshness metadata so a scanner knows whether it’s acting on live lines. Prediction market order books, by contrast, often require direct exchange websockets because no odds API aggregates them yet.
When should you build your own scanner instead of buying one?
Buy if your venues and markets are already covered and you just want alerts. Off-the-shelf scanners handle the common sportsbook-vs-sportsbook and sportsbook-vs-prediction-market pairs fine, and you can be running in an afternoon instead of maintaining a pipeline.
Build when at least one of three things is true. First, your edge depends on a venue the tools ignore, like a specific prediction market or an outlier book whose lines never make it into aggregated feeds. Second, the tool’s fee model is wrong for your math: if it flags arb without adjusting maker/taker fees and slippage, every signal needs manual verification anyway. Third, you need raw API access to feed a model, not just alerts.
The honest cost: you own polling, staleness detection, and uptime. If a cached line triggers a stale arb, that’s your bug, not your vendor’s.
How do you build a prediction market arbitrage scanner on an odds API?
Component architecture
Four components: an ingest layer, a normalization store, an edge calculator, and an alerter. The ingest layer pulls sportsbook lines from a normalized odds API and prediction market prices (midpoint of bid/ask) from exchange APIs on separate polling loops, since they move at different speeds. Store each snapshot with a captured-at timestamp so stale quotes never enter calculations.
Fee-adjusted edge module
For every cross-venue pair, compute the combined implied probability, then subtract venue fees, taker fees, and estimated slippage on both legs. An arbitrage only exists if the sum stays under 1.0 after those adjustments. Recompute on every snapshot, not on a timer, so line movement between polls doesn’t create phantom edges.
Alerting and stake sizing
Alert when the fee-adjusted edge clears your threshold, and size stakes inversely to each leg’s price so payouts match. Include the freshness timestamp in every alert; acting on a two-minute-old quote is how scanners lose money. For feed costs, indie-facing APIs run far below incumbents — Odds-API.io positions itself in that budget tier (Odds-API.io).
What should you pay for an odds feed that powers your scanner?
Budget matters more than brand here. The Odds API starts around $30/mo for 20K credits, which gets tight fast if your scanner polls line movement across many books. Odds-API.io and SportsGameOdds sit in similar territory, while TheRundown and SharpAPI target higher-end use cases.
PingOdds charges $5/mo for a starter tier and $20/mo for heavier usage, roughly a sixth of the-odds-api’s entry price. Every response carries freshness metadata, so your scanner can tell cached lines from live ones instead of firing on stale arb.
Honest caveats: PingOdds is a solo operation, so uptime and support depend on one person, and props coverage plus prediction market venues like Kalshi and Polymarket are still gaps where incumbents are broader. If you need those today, a $30 feed may be the cheaper option than building around missing coverage. If price is your binding constraint, the math favors switching.
FAQ
Is prediction market arbitrage still profitable after fees?
Sometimes, but margins are thinner than headline gaps suggest. Kalshi’s per-contract fee scales with fill price and can erase most of a 3% gross gap on its own, and thin order-book depth adds slippage. Profitable arbs are usually ones where the fee-adjusted edge survives both legs’ costs plus withdrawal fees, which means most signals you see are not real.
Can I use the-odds-api to build a Polymarket or Kalshi scanner?
Only half of one. The Odds API covers sportsbooks, not prediction market order books, so you’d still need to pull Polymarket and Kalshi prices directly from their exchange APIs and normalize the two data formats yourself. That’s workable, but you own the mapping between moneylines and contracts, plus staleness checks so cached sportsbook lines don’t fake an arb.
What’s the cheapest odds API for an arbitrage scanner?
PingOdds starts at $5/mo for a starter tier and $20/mo for heavier usage, versus roughly $30/mo for 20K credits at The Odds API. Odds-API.io and SportsGameOdds sit in similar budget territory. The tradeoff: incumbents have broader coverage, including prediction market venues, so the cheapest feed is only cheap if it covers your venues.
Do I need WebSocket streaming for arbitrage detection, or is polling enough?
Polling is usually enough. Prediction market dislocations can persist for minutes, so a 30-60 second poll catches them; sportsbook arbs die in seconds and want a 1-5 second poll or a stream. A practical compromise is polling longshot props where arbs linger and streaming only your main lines. Whatever you choose, check per-response freshness timestamps before acting.