← Back to blog
·12 min read·SettleRisk Team

Polymarket vs Kalshi: A Risk Scoring Comparison

polymarketkalshicomparisonrisk-scoring

Not all prediction market platforms carry the same resolution risk. Polymarket and Kalshi have fundamentally different dispute mechanisms, oracle structures, and resolution processes. Understanding these differences is essential for accurate risk pricing — and for anyone building trading strategies that span multiple venues. In this post, we break down how our scoring methodology treats each platform, walk through concrete scoring examples, and explain why resolution risk should be a first-class input to every prediction market trade.

Platform Base Points

SettleRisk assigns different base risk scores to each platform:

| Platform | Base Points | Rationale | |----------|------------|-----------| | Polymarket | 12 | Decentralized resolution, UMA oracle, community disputes | | Kalshi | 8 | CFTC-regulated, centralized resolution, defined data sources |

These base points reflect the inherent resolution complexity of each platform before any market-specific factors are considered. They are calibrated from historical dispute rates, average resolution timelines, and the structural properties of each platform's resolution pipeline. You can read the full derivation in our methodology documentation.

Why Polymarket Starts Higher

Polymarket uses the UMA optimistic oracle for dispute resolution. This means:

  1. Anyone can dispute — disputes are permissionless, increasing the probability of challenges
  2. Resolution requires consensus — the DVM (Data Verification Mechanism) involves token holder voting
  3. Timeline is variable — dispute resolution can take days to weeks depending on complexity
  4. Smart contract risk — resolution logic lives on-chain with immutable rules

These factors create a higher baseline resolution risk compared to a centralized exchange with a dedicated resolution team.

Why Kalshi Starts Lower

Kalshi operates as a CFTC-regulated exchange with:

  1. Centralized resolution — Kalshi's internal team resolves markets using pre-defined data sources
  2. Regulatory oversight — CFTC registration provides a dispute escalation path
  3. Standardized contracts — templated market structures reduce ambiguity
  4. Defined sources — resolution sources are specified in contract terms

However, Kalshi markets aren't risk-free. When the specified data source is unavailable (as in our Government API Outage case study), the centralized model can still produce significant delays.

Dispute Mechanisms Deep Dive

The dispute process is where the two platforms diverge most sharply. Understanding the mechanics matters because dispute probability is a direct input to the pricing engine — a higher p_dispute means a larger capital lockup adjustment.

Polymarket: UMA's DVM Voting Process

When a Polymarket outcome is proposed, it enters UMA's optimistic oracle pipeline. A proposer posts a bond and asserts an outcome. If no one disputes within the challenge window (typically two hours), the outcome is accepted and the market resolves. If someone disagrees, they post a counter-bond and the dispute escalates to the DVM.

The DVM is UMA's on-chain arbitration layer. UMA token holders vote on the correct resolution during a 48-hour commit phase followed by a 24-hour reveal phase. Voters who align with the majority are rewarded; those who vote with the minority are penalized. This creates an economic incentive for honest voting, but it also means that resolution depends on voter participation, the clarity of the resolution criteria, and the subjective interpretation of token holders who may not have deep domain expertise in the market's subject matter.

In practice, DVM votes can take 3-5 days from dispute initiation to final resolution. Complex or politically charged markets sometimes see multiple rounds of disputes, extending the timeline further. The permissionless nature of disputes also means that a single actor with sufficient capital can force a DVM vote on any market, regardless of whether the proposed outcome is obviously correct.

Kalshi: CFTC-Regulated Arbitration

Kalshi's resolution process is centralized and operates under CFTC oversight. When a market reaches its expiration, Kalshi's operations team resolves it according to the contract's pre-specified data source. If the BLS releases a jobs number and the contract references that exact release, resolution is mechanical.

Disputes on Kalshi follow a formal arbitration path. Traders can submit complaints to Kalshi's compliance team, which reviews the resolution against the contract terms. If unresolved, the dispute can be escalated to the CFTC's reparations process. This regulatory backstop provides certainty about the process, but it is slow — CFTC complaints can take weeks to months. The tradeoff is that Kalshi disputes are rare precisely because the resolution criteria tend to be more tightly specified, but when they do occur, the resolution timeline can exceed even Polymarket's DVM process.

How Drivers Differ by Platform

The same driver type can manifest differently across platforms:

SINGLE_ORACLE_DEPENDENCY

  • Polymarket: Often depends on UMA oracle + a specific data API. If the data source disagrees with UMA voters, disputes escalate.
  • Kalshi: Typically depends on a single government or financial data source. If that source is down, resolution stalls.

AMBIGUOUS_WORDING

  • Polymarket: Community-written resolution criteria tend to be more informal, increasing ambiguity risk.
  • Kalshi: Standardized contract templates reduce but don't eliminate wording ambiguity.

TEMPORAL_AMBIGUITY

  • Polymarket: Markets often use informal time references ("by end of day") without timezone specifications.
  • Kalshi: Contract terms typically specify ET (Eastern Time) by default, reducing timezone disputes.

Historical Dispute Patterns

The base points are not theoretical — they are grounded in observed platform behavior. Here is a summary of average dispute rates and resolution timelines across both platforms:

| Metric | Polymarket | Kalshi | |--------|-----------|--------| | Dispute rate (% of markets) | ~4.2% | ~0.8% | | Median resolution time (undisputed) | 2-4 hours | 1-2 hours | | Median resolution time (disputed) | 4-7 days | 2-6 weeks | | Average capital lockup during dispute | 5.1 days | 18.3 days | | Escalation rate (dispute to full arbitration) | ~35% (DVM vote) | ~12% (CFTC complaint) |

These numbers illustrate a key asymmetry: Polymarket has more frequent but shorter disputes, while Kalshi has rarer but longer-running disputes when they do occur. Our case studies cover several of these in detail.

Polymarket: The 2025 Election Runoff Dispute

One of the most visible Polymarket disputes involved a state election runoff market where the resolution criteria referenced "certified results." After the initial count, one candidate led, but a recount was triggered. UMA proposers asserted the pre-recount result, a dispute was filed, and the DVM vote ultimately sided with waiting for certification. The market was locked for 11 days — far longer than the original 2-hour optimistic window suggested. This case is examined in depth in our election resolution case study.

Kalshi: The Government API Outage

A Kalshi economic data contract specified resolution based on a specific government API endpoint. When that endpoint experienced an extended outage during a federal IT migration, Kalshi could not mechanically resolve the market. The resolution was delayed by 19 days while the operations team determined an alternative authoritative source. Despite Kalshi's lower base risk, the SINGLE_ORACLE_DEPENDENCY driver pushed this particular market's score into HIGH territory. See the full analysis in our Government API Outage case study.

Polymarket: The Crypto ETF Approval Ambiguity

A Polymarket contract on "SEC approves a spot Bitcoin ETF by Q1 2025" generated disputes around what "approves" meant — was it the 19b-4 filing approval, or the S-1 effectiveness declaration? Different participants interpreted the resolution criteria differently, and the DVM vote was unusually close. This type of AMBIGUOUS_WORDING driver is precisely what SettleRisk's LLM extraction pipeline is designed to detect. Our methodology explains how we identify ambiguous clauses in resolution text.

Scoring in Practice

Consider a market on "Fed Rate Cut by March 2027" on both platforms:

Polymarket version (score: 73, HIGH):

  • Base: 12
  • EXTERNAL_DEPENDENCY: 9 points (Fed decision timing)
  • MULTI_STEP_RESOLUTION: 10 points (FOMC -> announcement -> confirmation)
  • TEMPORAL_AMBIGUITY: 11 points ("by March" — which day?)
  • Additional complexity: +31

Kalshi version (score: 52, HIGH):

  • Base: 8
  • EXTERNAL_DEPENDENCY: 9 points (same dependency)
  • MULTI_STEP_RESOLUTION: 10 points (same process)
  • TEMPORAL_AMBIGUITY: 5 points (contract specifies exact FOMC meeting date)
  • Additional complexity: +20

The 21-point gap comes from Polymarket's higher base score and less precise temporal specification.

Second Example: Crypto Regulation Market

Now consider a more complex scenario — a market on "US passes comprehensive crypto regulation by December 2027" listed on both platforms:

Polymarket version (score: 88, CRITICAL):

  • Base: 12
  • AMBIGUOUS_WORDING: 14 points ("comprehensive" is undefined — what qualifies?)
  • MULTI_STEP_RESOLUTION: 12 points (committee vote -> floor vote -> signing -> effective date)
  • TEMPORAL_AMBIGUITY: 8 points ("by December" without specifying signing vs. effective date)
  • EXTERNAL_DEPENDENCY: 10 points (Congressional schedule, presidential action)
  • SUBJECTIVE_RESOLUTION: 13 points (UMA voters must interpret "comprehensive")
  • Additional complexity: +19

Kalshi version (score: 64, HIGH):

  • Base: 8
  • AMBIGUOUS_WORDING: 6 points (contract defines "regulation" as a specific bill number or any bill amending the Securities Act)
  • MULTI_STEP_RESOLUTION: 12 points (same legislative process)
  • TEMPORAL_AMBIGUITY: 4 points (contract specifies "signed into law by 11:59 PM ET Dec 31, 2027")
  • EXTERNAL_DEPENDENCY: 10 points (same dependency)
  • SUBJECTIVE_RESOLUTION: 5 points (Kalshi's criteria are more mechanical)
  • Additional complexity: +19

The 24-point gap here is even wider than the Fed example. The SUBJECTIVE_RESOLUTION and AMBIGUOUS_WORDING drivers hit Polymarket much harder because UMA voters must interpret vague language, while Kalshi's contract template narrows the definition upfront. This market crosses into CRITICAL territory on Polymarket, which means p_dispute jumps significantly due to the critical tier indicator in our scoring formula.

Cross-Platform Arbitrage and Resolution Risk

One of the most common questions we hear: "If the same event is listed on both platforms, can I arb the price difference?" The short answer is yes, but resolution risk makes it far more nuanced than spot market arbitrage.

When you buy YES on one platform and NO on the other for the same event, you are not entering a risk-free trade. You are entering a trade whose risk is dominated by resolution basis — the possibility that the two platforms resolve the same real-world event differently, or at different times.

Resolution divergence risk is real. Different resolution criteria, different data sources, and different dispute timelines mean that a market can resolve YES on Kalshi and remain in dispute on Polymarket for days. During that window, your capital is locked on both sides. If the Polymarket dispute ultimately resolves differently than you expected, your "arbitrage" becomes a loss.

Timing mismatch creates financing cost. Even when both platforms eventually agree on the outcome, the faster-resolving platform releases your capital days or weeks before the slower one. That capital lockup has a cost, especially in volatile rate environments.

SettleRisk's expected delay model quantifies this directly. By comparing expected_delay distributions across platforms, you can estimate the probability that one platform resolves more than N days after the other — and price that financing cost into your arb spread requirement. Our features page covers the expected delay API in detail.

A practical rule of thumb: if the SettleRisk score differential between platforms exceeds 15 points, treat the cross-platform position as a directional bet on resolution convergence, not as an arbitrage. Price it accordingly.

Implications for Traders

If you're trading the same event on both platforms:

  1. The Kalshi contract is cheaper to hold — lower dispute probability means lower capital lockup risk
  2. Polymarket may offer better prices — higher risk means wider spreads, creating opportunities for informed traders
  3. Hedging across platforms introduces basis risk — different resolution timing and criteria mean cross-platform hedges aren't perfect
  4. Score differentials above 15 points signal meaningful resolution divergence — factor this into your position sizing and hedge ratios

Using SettleRisk for Cross-Platform Analysis

Python:

from settlerisk import SettleRiskClient

client = SettleRiskClient(key_id="vx_...", secret="...")

# Compare the same event across platforms
poly_score = client.get_risk_score("polymarket", "0xfed123")
kalshi_score = client.get_risk_score("kalshi", "KXFED-27MAR")

print(f"Polymarket risk: {poly_score['aggregate_risk_score']}")
print(f"Kalshi risk: {kalshi_score['aggregate_risk_score']}")

# Check expected delay differential
poly_delay = client.get_expected_delay("polymarket", "0xfed123")
kalshi_delay = client.get_expected_delay("kalshi", "KXFED-27MAR")

print(f"Polymarket p95 delay: {poly_delay['p95_hours']}h")
print(f"Kalshi p95 delay: {kalshi_delay['p95_hours']}h")

TypeScript:

import { SettleRiskClient } from "@settlerisk/sdk";

const client = new SettleRiskClient({
  keyId: "vx_...",
  secret: "...",
});

// Compare the same event across platforms
const polyScore = await client.getRiskScore("polymarket", "0xfed123");
const kalshiScore = await client.getRiskScore("kalshi", "KXFED-27MAR");

console.log(`Polymarket risk: ${polyScore.aggregateRiskScore}`);
console.log(`Kalshi risk: ${kalshiScore.aggregateRiskScore}`);

// Check expected delay differential
const polyDelay = await client.getExpectedDelay("polymarket", "0xfed123");
const kalshiDelay = await client.getExpectedDelay("kalshi", "KXFED-27MAR");

const delayGap = polyDelay.p95Hours - kalshiDelay.p95Hours;
console.log(`P95 delay gap: ${delayGap.toFixed(1)} hours`);

if (polyScore.aggregateRiskScore - kalshiScore.aggregateRiskScore > 15) {
  console.log("Warning: score differential suggests resolution divergence risk");
}

The score differential tells you which platform carries more resolution risk — and which one is a better venue for your specific trade. The delay differential tells you how much financing cost to expect if you are holding positions across both.

Start Quantifying Resolution Risk Today

Resolution risk is the hidden cost of prediction market trading. Whether you are running cross-platform arbitrage, sizing single-venue positions, or building automated trading systems, the difference between Polymarket's 12-point base and Kalshi's 8-point base is just the beginning. Market-specific drivers — ambiguous wording, oracle dependencies, temporal gaps — can push scores apart by 20 points or more, fundamentally changing the risk profile of what looks like the same trade.

SettleRisk gives you the data to make these decisions quantitatively instead of by gut feel. Explore our live demo to see scoring in action, review our full case studies for real-world dispute examples, or check out our pricing plans to integrate resolution risk directly into your trading pipeline.

Try the API free for 14 days — no credit card required.