aifinhub

Methodology · Comparator · Last updated 2026-04-20

How Kalshi vs Polymarket Arb Scanner works

How the Kalshi vs Polymarket Arb Scanner tool actually works — assumptions, algorithms, limitations.

Status

Initial release ships with a synthetic reference dataset so the tool UX is live while the refresh pipeline is being connected. A scheduled GitHub Action that pulls Kalshi and Polymarket public APIs, pairs contracts, and commits public/data/kalshi-poly-arb/latest.json lands in a follow-up release.

Pairing algorithm (when live)

  1. Pull open Kalshi and Polymarket markets via their respective public APIs.
  2. Normalize resolution criteria to a structured tuple: (subject, metric, threshold, resolution_by).
  3. Candidate pair any Kalshi and Polymarket market with matching normalized tuple.
  4. Human-curator review for cases where resolution criteria differ materially between venues (e.g. different data sources).
  5. Emit pairs with both venues' current ask quotes, volumes, and open interest.

Edge math

gross_edge = 1 − (yes_kalshi + no_polymarket)   # or swap venues
         OR  1 − (no_kalshi + yes_polymarket)

gross_edge_bps  = round(gross_edge × 10000)
net_edge_bps    = gross_edge_bps − fees_bps − slippage_bps
expected_pnl    = (capital / 1) × net_edge_bps / 10000

Fees + slippage assumptions

  • Kalshi: CFTC-regulated exchange fees (tiered by contract type). Modeled at 60–80 bps for the paired side.
  • Polymarket: 2% maker / taker-structure; modeled at 60 bps effective.
  • Slippage: a conservative 30–60 bps for $1K notional; scales with order book depth reported in dataset.

These are assumptions, not quotes. Real fills vary. The tool shows the assumed breakdown so you can substitute your own numbers.

Resolution-risk overlay

Each pair carries a structured resolution.risks array flagging:

  • Ambiguous resolution criteria between venues
  • Liquidity vanishing risk near resolution
  • Mid-period rebasing or revision risk for metric-based markets
  • Oracle disagreement risk (specific to Polymarket's UMA oracle)

Refresh cadence

When the GitHub Action ships: daily at 12:00 UTC. The JSON file is committed to the repo and served from Cloudflare Pages' CDN. No backend, no queue, no ops burden.

Compliance notes

  • Not investment advice. Education only, per BaFin and EU framework.
  • Kalshi is CFTC-regulated and accessible to US residents. Non-US access is restricted.
  • Polymarket is accessible via web3 wallets but has varying access restrictions by jurisdiction. Users are responsible for confirming eligibility under their local regulations.
  • Tax treatment of prediction-market winnings is jurisdiction-specific. Swap-contract, gambling, or ordinary-income treatment all appear in various jurisdictions.

Limitations

  1. Paired-contract coverage is incomplete. Many markets exist on only one venue; the tool silently ignores those.
  2. Depth is a single snapshot. The dataset records top-of-book only; real fills on $10K+ notional will slip further than the modeled slippage.
  3. Daily refresh. Short-lived arbs that resolve within hours won't appear. For high-frequency coverage, subscribe to both venues' real-time feeds yourself.
  4. Synthetic launch data. The first dataset is illustrative. Live data replaces it on the first Action run.
Planning estimates only — not financial, tax, or investment advice.