Statistical Arb Between Polymarket and Kalshi Correlated Events
Identifies co-integrated prediction-market pairs — identical underlying events priced on both venues — and builds a mean-reversion signal using the Engle-Granger two-step procedure. Shows how to hedge execution risk given Polymarket's on-chain settlement lag.
Prediction markets have matured enough that the same real-world binary outcome often trades simultaneously on Polymarket and Kalshi. When that happens you have two price series that must converge to the same {0, 1} terminal value — a textbook setup for statistical arbitrage. The mechanics are not obvious, though: settlement infrastructure, liquidity profiles, and regulatory constraints differ enough that naive spread-trading will bleed you dry on transaction costs and execution slippage before the edge compounds. Here is how to do it properly.
Finding Co-integrated Pairs
Start with a universe of events that share an unambiguous underlying. "Will the Fed cut rates at the November 2025 FOMC meeting?" resolves identically on both venues given the same resolution criteria. That is your candidate. Events where wording diverges even slightly — "cut by at least 25 bps" vs. "cut rates" — are not the same instrument and will diverge for fundamental reasons, not noise.
Run the Engle-Granger two-step on daily closing-price histories for each candidate pair. Step one: regress the Polymarket YES price ($P$) on the Kalshi YES price ($K$) with an intercept. Step two: apply an Augmented Dickey-Fuller test to the residuals. You want ADF statistic below -3.0 (5 % critical value) and a p-value under 0.05. Pairs that fail this test are not co-integrated — the spread is a random walk and you have no mean-reversion edge, only noise.
In practice, roughly 40–60 % of event pairs that look qualitatively identical will actually pass the ADF test at your threshold. Many fail because Kalshi's regulated structure introduces intermittent price gaps around earnings blackouts or compliance holds that break the stationarity assumption. Filter these out before sizing any position.
Building the Mean-Reversion Signal
Once you have a validated pair, the spread is:
s_t = P_t - β * K_t - α
where α and β are your OLS estimates from step one. β is rarely 1.0; Kalshi prices carry a slight regulatory premium in some markets (users perceive less counterparty risk), so you will often find β in the range 0.92–1.05.
Track the rolling Z-score of the spread with a 20-day lookback:
z_t = (s_t - μ_s) / σ_s
Enter long Polymarket / short Kalshi when z falls below -1.5, reverse when z exceeds +1.5. Exit flat at z = 0 or when either market resolves within 7 days of expiry — at that horizon, carry and settlement risk swamp the edge. Do not use static thresholds; recalibrate α, β, μ, and σ on a rolling 30-day window. Prediction-market correlations shift as event probability approaches 0 or 1 because the distributions become increasingly non-Gaussian near the tails.
Hedging Polymarket's On-Chain Settlement Lag
This is where most implementations fail. Kalshi settles in T+0 cash via ACH or wire. Polymarket settles on Polygon: after an event resolves, the UMA optimistic oracle dispute window runs for two hours before USDC is unlocked. If resolution is disputed — rare but not impossible on contentious political events — that window extends to 48 hours or more.
The practical hedge is position sizing, not a derivatives overlay. Keep your Polymarket notional small enough that a 48-hour settlement freeze does not breach margin on the Kalshi leg. A 3:1 Kalshi-to-Polymarket notional ratio is conservative but survivable. You are also exposed to gas-spike risk at settlement time on Polygon; pre-fund a hot wallet with enough MATIC to cover a 200 Gwei settlement transaction, otherwise you will be stuck waiting while the Kalshi leg moves against you.
For events with particularly high dispute probability — anything touching election integrity or regulatory outcomes — run an additional overlay: buy a small OTM position on the opposite side of your Polymarket leg one week before expiry. This acts as a cheap insurance leg against the scenario where resolution is delayed and the Kalshi leg settles first at a price that moves against you.
Sizing and Transaction Cost Reality
Kalshi charges a maker/taker fee of approximately 7 bps per side. Polymarket has no explicit fee but USDC/Polygon bridge costs and gas add 5–15 bps depending on network congestion. Round-trip friction is roughly 25–35 bps per trade. Your edge needs to exceed this, with room for spread widening on exit.
In our production bot infrastructure, we gate entry on expected edge (E[|z_entry - z_exit|] * σ_s * β) exceeding 60 bps after costs. Positions that do not clear this hurdle are skipped regardless of Z-score signal strength. This filter alone cuts trade frequency by about 35 % but improves Sharpe by more than 0.4 on backtests.
Position limits per event pair:
- Max 2 % of portfolio notional per pair
- Max 5 % aggregate prediction-market exposure at any time
- Hard stop if unrealized loss exceeds 1.5x the estimated edge on entry
Liquidity and Market Microstructure Nuances
Neither venue has the order book depth you get in futures. Kalshi's top-of-book for a mid-popularity event might be $20k–$80k; Polymarket can be thinner on less trafficked markets. Always simulate full order-book impact before live execution. We split orders into 5–10 child orders over 10–15 minutes to avoid adverse selection — a single large lift telegraphs intent to market makers who will immediately widen the spread you are trying to capture.
Monitor open interest on both legs in real time. A sudden OI spike on either venue often precedes a re-rating event — a news release, a leaked report, or a whale entering. If OI spikes more than 20 % on either leg before your position is fully entered, abort and wait for the new equilibrium to establish.
If you want this strategy running in production rather than in a spreadsheet, talk to us at TierZero — we build, deploy, and operate execution infrastructure exactly like this.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article