Polymarket × Kalshi arbitrage: how it works in 2026

The opportunity, plainly

Polymarket and Kalshi are both order-book venues for event outcomes. Polymarket is on-chain (Polygon), CLOB-style, and has historically geo-fenced US users. Kalshi is CFTC-regulated, accessible to US residents, and runs on traditional exchange infrastructure. Both list contracts on similar underlying events — sometimes near-identical events, sometimes equivalent contracts with slightly different resolution criteria.

When market participants react to news at different speeds on the two venues — or when one venue's liquidity is thinner than the other — the implied probabilities diverge. The simple arbitrage is to buy the cheaper "yes" on one venue and short or buy "no" on the other, locking in a guaranteed payout regardless of the event's outcome. Gross spreads of 2-5% on news days are not unusual; structural spreads of 30-100 basis points are common in liquid contracts.

Why it's harder than it looks

Execution latency

Polymarket trades are on-chain. Block times on Polygon are short but non-zero, and the Polymarket Builder Relayer's gasless execution still introduces a relay-side queue. Kalshi runs on traditional exchange infrastructure with millisecond-or-better confirmation. The latency mismatch means by the time your Polymarket leg confirms, the Kalshi price you were arbing against may have moved.

Single-leg execution risk

The single biggest failure mode in this strategy: one leg fills and the other doesn't. Now you have a directional position you didn't intend, often into a news event where prices are moving against you. Atomic execution — file both orders only when both venues confirm liquidity at the desired prices — is the mitigation, but truly atomic cross-venue execution is hard. Most practical implementations use tight time-to-fill thresholds (e.g. "if both legs don't confirm within 500ms, kill the trade") and smaller position sizes so partial fills are recoverable.

Fee and slippage drag

Polygon gas (small but nonzero), Polymarket maker/taker fees, Kalshi exchange fees, slippage on both venues — every basis point eats into the arbitrage spread. A 2% gross spread can become a 0.5% net spread once all execution costs land. Sizing the trade so the net spread covers a meaningful return on the capital deployed is the operational discipline that separates profitable arbitrage operators from breakeven ones.

Regulatory geometry

Polymarket geo-fences US residents. Kalshi welcomes them. Running both legs as a US retail trader is at best in a regulatory grey-zone; at worst it puts the Polymarket account at compliance risk. The most credible operators in this strategy are running the Polymarket leg from a non-US jurisdiction or via a venue Polymarket explicitly permits. The regulatory landscape is evolving — CFTC-regulated prediction-market venues are expanding through 2025-2026 and the rules will keep changing. Verify current jurisdictional status at trade time.

The tooling that ships today

NautilusTrader (open-source)

Community-maintained adapters exist for both Polymarket and Kalshi. Building a cross-venue arbitrage strategy in NautilusTrader is achievable for a Python-comfortable quant — the framework handles event-driven execution and provides the atomicity primitives you need. The infrastructure work (hosting, RPC providers, monitoring) is on you. See our NautilusTrader review.

Minmax (closed beta, expanding roadmap)

Minmax has Kalshi on its public roadmap. The continuous data recorder is running on Kalshi markets ahead of full execution support — the depth-of-data argument that applies to the Polymarket leg will apply to the Kalshi leg once recording is long enough. A turnkey cross-venue arbitrage product is not yet in production, but the underlying infrastructure makes it the natural place for one. See our Minmax review.

Custom builds

Most practitioners in this strategy are running custom infrastructure today — a thin Python service with direct Polymarket Builder API access on one side and the Kalshi exchange API on the other, atomicity-checked with custom logic. The barrier to entry is meaningful but not enormous. Expect to spend 2-4 weeks building the first working version, then continuously on operational tuning.

What to plan for before deploying capital

• Jurisdiction. Confirm both Polymarket and Kalshi access for the account you're trading from. Mismatch is the avoidable mistake.
• Capital allocation. Position sizes that make a partial fill non-catastrophic. The cost of a hung leg dominates the upside of a clean arbitrage; size accordingly.
• Atomicity logic. Time-to-fill thresholds (sub-second on liquid contracts, longer on illiquid ones), partial-fill unwind rules, kill-switch monitoring.
• Operational monitoring. When a leg hangs, you need to know in seconds, not minutes. Build dashboards before you build size.
• Regulatory contingency. What happens if Polymarket loses your jurisdiction, or Kalshi delists a contract you're holding? Plan exit liquidity.

The take

Polymarket × Kalshi arbitrage is one of the few prediction-market strategies with a structural reason to exist — two venues, same underlying events, latency and liquidity mismatches that don't fully clear. The opportunity is real and capacity-constrained, which means the operators who do it well take it seriously about infrastructure. For a 2026 retail trader, the most realistic entry path is custom code on NautilusTrader; for institutional deployment, Minmax's roadmap is the natural place to watch.