// PREDICTION-MARKET APIS

Unified market IDs: mapping the same event across Kalshi and Polymarket

2026-07-16 · Mithril

Ask a simple question — "what does the same market cost on Kalshi versus Polymarket?" — and you hit an unglamorous wall before you can even fetch a price: there is no shared identifier. Kalshi calls a market FED-26SEP-T4.00; Polymarket calls what looks like the same bet 0x26d06d9c... with two outcome token IDs hanging off it. Nothing in either API points at the other. Every cross-venue system — price comparison, smart order routing, arbitrage — has to solve the mapping problem first, and it is harder than it looks.

Why no shared identifier exists

Equities have this problem solved by fiat: ISINs, CUSIPs, exchange symbol files. Prediction markets have nothing equivalent, for structural reasons:

• The venues define their own contracts. A Kalshi market is a CFTC-regulated contract with rules text written by the exchange; a Polymarket market is a question with resolution criteria resolved via its own oracle process. Nobody upstream issues "the event" as a canonical object with an ID — each venue mints its own.
• The identifier schemes encode different things. Kalshi tickers are structured strings (series–event–strike, roughly FED-26SEP-T4.00) designed for humans. Polymarket's condition_id is a hash-derived hex string, with a separate ERC-1155 token_id per outcome, designed for smart contracts. There is no field to join on — not name, not date, not category.
• The market structures differ. Kalshi expresses a range of outcomes as many binary markets under one event (a strike ladder); Polymarket may express the same question as one multi-outcome event or a different set of binaries. Sometimes the honest mapping is one-to-many or many-to-many, not one-to-one.

So a mapping has to be built — by matching on titles, dates, categories, and rules text — and then maintained as both venues list new markets daily.

The matching pitfalls

Naive matching (fuzzy title similarity plus a date check) gets you a mapping that is mostly right, and "mostly right" is dangerous, because you will route real orders across it. The failure modes:

Different resolution criteria

Two markets can share a headline and resolve differently. "Fed cuts rates in September" might resolve on the target-range midpoint at one venue and on any downward change at the other; an inflation market might use month-over-month at one venue and year-over-year at the other; a political market might depend on who is inaugurated versus who wins certification. The resolution rules text is the contract. If the criteria differ, the markets are correlated but not identical — treating them as identical turns "arbitrage" into a correlated bet with tail risk exactly in the scenarios where the criteria diverge.

Different resolution dates and times

Same question, different clock: one market resolves at end of month, the other at end of quarter; one uses the announcement time, the other the publication of official data. A price gap between them may just be the time difference, not an edge.

Different sources of truth

One venue resolves on a named government data series; the other on "credible reporting" or an oracle's judgment. In the easy cases these agree. Your PnL, however, lives in the hard cases.

Structural mismatches

A Polymarket multi-outcome event ("who wins the nomination") versus a Kalshi ladder of per-candidate binaries; strike boundaries that almost but don't quite align (above 4.00% vs 4.00% or higher — is the boundary in or out?). Mapping a strike ladder to a set of outcome tokens is a correspondence between structures, and off-by-one boundary conventions are the classic silent error.

Drift

Markets get amended, clarified, and occasionally re-listed. A mapping validated at listing time can be wrong by resolution time. Mappings need revalidation, not just creation.

What a unified ID actually is

A unified market ID — Mithril's are mkt_ identifiers — is a canonical key for "one economic bet", with venue legs attached:

{
  "id": "mkt_fed_sep26_above_400",
  "question": "Fed target rate above 4.00% after the Sept 2026 meeting",
  "venues": {
    "kalshi": { "ticker": "FED-26SEP-T4.00" },
    "polymarket": {
      "condition_id": "0x26d06d9c...",
      "yes_token_id": "7132...",
      "no_token_id": "2489..."
    }
  },
  "equivalence": "exact",
  "resolution_notes": "Both resolve on the upper bound of the announced target range."
}

The two fields that separate a serious mapping from a toy:

• An equivalence grade. Exact (same criteria, same date, same source), near (economically equivalent with documented edge cases), or related (correlated, not interchangeable). Routing should only ever cross exact mappings; research can use the rest.
• Resolution notes. The recorded human judgment about why the legs are equivalent — because the equivalence decision is ultimately a reading of two rules texts, and you want it auditable when a market resolves strangely.

Building the pipeline behind this is candidate generation (titles, dates, categories) followed by verification against the actual rules — automation proposes, verification disposes — plus ongoing revalidation as markets are amended and new ones list.

What unified IDs unlock

Once "one bet, N venues" is a first-class object, the cross-venue features become straightforward:

• True price comparison. Quote the same bet from both books in one normalized form — and then compare net prices, because Kalshi's formula-based taker fee and Polymarket's spread-plus-gas cost model make displayed prices non-comparable (the differences that bite covers this).
• Smart order routing. "Buy 500 yes of mkt_..." becomes a routing decision — which venue, or which split — made per order on net price. That is what routing does, and it is only well-defined on top of an exact-grade mapping.
• Cross-venue positions and risk. Exposure to the event is the sum across legs; a risk system that caps per-market notional needs the unified key, or a bot can double its intended exposure by holding the "same" market twice under two names.
• Arbitrage with eyes open. The equivalence grade is exactly the risk disclosure an arbitrage strategy needs: exact mappings are the trade; near mappings are a different, riskier trade.

Build or buy

A cross-venue mapping is a living dataset: candidate matching, rules verification, equivalence grading, and revalidation, forever, as both venues list markets daily. If your edge is the strategy rather than the reference data, this is a strong candidate for buying: Mithril maintains unified mkt_ IDs across Kalshi and Polymarket as part of its API, so an order against one ID is routed for best net price across both venues — with an execution receipt showing what you got. If you build instead, budget for the maintenance, and grade your equivalences honestly: the mapping is a place where a data bug becomes a position.

APIs change. Details above reflect public documentation as of July 2026 — always confirm against the venues' own docs before trading real money.