Methodology

We ingest live data from each platform's public API. No private or paid feeds are used.

• Polymarket — the public Gamma API at gamma-api.polymarket.com. Markets, events, prices, volumes, and order book snapshots.
• Kalshi — the public Trading API at api.elections.kalshi.com/trade-api/v2. Markets, events, contract specifications, prices, and per-outcome open interest.
• Limitless — the public Limitless Exchange API. Markets, prices, and volumes from the Base-network deployment.
• Hyperliquid — the public Hyperliquid info API for select prediction-style markets and oil/commodity perpetuals referenced in editorial coverage.

Each platform's sync runs on its own schedule:

• Full market sync: every 30 minutes. Walks the entire active market list per platform and updates prices, volumes, status, and metadata.
• Canonicalization sweep: every 10 minutes. Considers any unlinked market with $10K+ lifetime volume and attempts to link it to an existing canonical event before creating a new one.
• Arbitrage scan: every 5 minutes. Re-evaluates the canonical event graph for cross-platform spreads and produces the live opportunities list at /arbitrage.
• Stale cleanup: markets and events past their resolution date but not yet flagged closed are reviewed each cycle.

The hard problem in prediction-market aggregation is identifying when two contracts on different platforms are pricing the same underlying event. Polymarket and Kalshi never use the same contract title, market structure, or outcome names. Our pipeline solves this in three layers:

1. Volume-based discovery. Any market with $10K+ in lifetime volume that is not already linked to a canonical event is a candidate. There are no hardcoded keyword filters; the system is fully discovery-driven.
2. Structured identity extraction. An LLM extracts a structured identity from the candidate market: event type, year, party (where applicable), and key terms. The identity is the LLM's best attempt at a platform-agnostic description of what the contract is actually about.
3. Search-and-validate. The pipeline searches the target platform with multi-term OR queries derived from the structured identity. Candidate matches are scored, validated against scope checks (e.g. a Conference final is not a championship final), and only stored if the LLM's match confidence clears a threshold. Each match records the LLM's reasoning so it can be audited.

Stable IDs of the form ce_{eventType}_{year}_{party}_{keyterms} ensure the same canonical event is not created twice across runs. A separate process flags conflicts for human review.

Each canonical event stores a list of canonical outcome names — the most disambiguated version of each option. Per-platform contracts map their local outcome names to canonical names through a stored outcome mapping. Comparison tables, arbitrage detection, and price spreads all operate against canonical outcomes, so a Polymarket "Trump" contract and a Kalshi "Donald Trump" contract appear as the same row.

• Polymarket prices are decimals on the [0, 1] interval. Price changes are stored as decimals (0.05 = 5 percentage points).
• Kalshi prices arrive in cents on the [0, 100] interval and are divided by 100 before storage and display.
• Volumes are normalized to USD-equivalent dollar volume traded.
• Multi-outcome events sum volume across all child markets, so the event total may exceed any single child market.
• Kalshi multi-outcome liquidity: Kalshi reports a single liquidity_dollars figure for the entire pool. We use per-outcome open_interest when allocating per-outcome liquidity figures.

The arbitrage scanner deducts platform fees before reporting net profit and annualized return.

• Polymarket: 0% trading fee. Cost is the bid/ask spread, which we approximate as zero. The order book may move in size, so reported profit is an upper bound for non-trivial trade sizes.
• Kalshi: price-dependent fee of min(7¢, 7% × price × (1 − price) × 100) per contract, charged on both buy and sell. Fees peak at ~7¢ per $1 notional near 50/50 prices and approach zero at extreme prices.
• Annualized return is calculated as net_profit_pct × (365 / days_to_resolution) — a simple (non-compounding) annualization, since the same arb cannot be reinvested.

The single largest hidden risk in cross-platform prediction-market arbitrage is that two platforms can resolve the same nominal event differently. The textbook example: in 2024, Polymarket and Kalshi both listed a market on whether Cardi B would perform at the Super Bowl. Polymarket resolved YES based on her stadium appearance; Kalshi resolved NO because she did not perform on the official halftime stage. Both platforms followed their published rules.

We surface a settlement-risk banner on the arbitrage scanner and flag known-different rule sets where applicable, but contract terms can change. Always read the resolution criteria on each platform before executing an arbitrage trade. See our deep-dive on settlement risk for a longer treatment.

Analysis articles are written from the data up. Every claim is grounded in a specific number, a specific market, or a specific transaction. Articles include:

• The data window covered (start and end timestamps).
• Direct links to the underlying canonical events and per-platform markets.
• Methodology callouts whenever a non-trivial transformation is applied to the source data.
• Update notes when markets resolve after publication.

We do not publish forecasts of our own. The prediction markets are the forecast; the editorial layer reports what they say.

• Match precision is not 100%. Despite scope checks and confidence thresholds, the LLM-based canonicalization pipeline occasionally produces incorrect matches. We continually audit and re-run the canonicalization sweep; reported errors are corrected on the next cycle.
• Sub-question filtering. Individual binary "Will candidate X be nominated?" markets are filtered out of canonical-event discovery to prevent duplicating multi-outcome canonical events. They remain reachable at their direct market URLs.
• Order-book depth is not modeled. Reported arbitrage profit assumes both sides fill at the displayed price. Real fills may slip, especially for large size on thinly-traded markets.
• Limited historical backfill. Price history for older markets may have gaps where the source API did not return granular tick data.