Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) `topic` — 11 pre-mapped macro subjects ("fed", "btc", "eth", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. You do NOT have to use those exact keys: the topic is resolved through aliases and keywords, so "bitcoin", "fed rate decision", "inflation", "s&p 500" and "next pope" all land on the right subject, and `resolution.topic_matched_by` tells you whether it was an exact key, a known alias, a phrase found inside a longer question, or a single-keyword guess — treat "phrase" and "token" as a GUESS at what you meant. An unresolvable topic returns error:"mapping_failed" with mapping_stage:"topic_unrecognized" and known_topics[]; it never silently falls back to a default subject. (2) explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. `resolution` is returned in BOTH modes and says how each side's identifier was picked (which Kalshi series was queried, how many events came back, whether the chosen one had quoted markets; which Polymarket search query ran and why that event won). Fleet #2064: when two Polymarket candidates tie on resolution time `polymarket_selected_by` now SAYS so, names every tied slug, names the tie-break that actually decided it (the candidate whose metric_type matches the Kalshi series, else lexicographic slug order), and states whether the winner's metric matches the Kalshi series — it used to assert "picked the soonest-resolving" byte-identically on calls that returned DIFFERENT events, because the tie was settled by upstream fetch arrival order. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (the two events are about different SUBJECT months — e.g. Kalshi "CPI in October" vs Polymarket "September Inflation"), temporal_alignment_unknown (the subject month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events are about the same SUBJECT calendar period, in EITHER mode — this is the period the question is ABOUT (e.g. "September" for a CPI release that settles in October), not necessarily when either side settles; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. Fleet #2062: this used to compare Polymarket's settlement date against Kalshi's subject month and call a match — fixed to compare subject month to subject month on both sides. FEES: every top_spreads_pp and low_confidence_pairs[] row carries edge_pp_gross (== |spread_pp|), fees_pp, edge_pp_net, net_positive, and BOTH venues' taker fees itemised as kalshi_fee_pp and polymarket_fee_pp (plus polymarket_fee_rate, polymarket_fee_category, polymarket_fee_basis). Kalshi leg: fee = ceil(0.07 * contracts * P * (1-P) * 100) / 100 dollars per order, verified against kalshi.com/docs and corroborating explainers as of 2026-09-12. Polymarket leg: fee = shares × rate × p × (1-p) with rate by category (crypto 0.07, sports/economics/culture/weather/other 0.05, finance/politics/mentions/tech 0.04, geopolitics and world events fee-free), verified against Polymarket's own docs as of 2026-09-13 and read off each market's published fee parameters rather than inferred. Both amortized at a 100-contract reference size. Before fleet #1927 the Polymarket leg carried modeled gas only, which made every edge_pp_net here optimistic by up to ~1.75pp; spreads that no longer clear are the correction. Spread-crossing cost is still NOT modeled on the Polymarket leg (no live order book is fetched by this tool). spread.fees_note carries the same disclosure. RESOLUTION EQUIVALENCE (fleet #1909): every top_spreads_pp and low_confidence_pairs[] row now also carries resolution_equivalent ("true"|"false"|"unclear") and, when not "true", resolution_warning naming what differs — computed ONCE per event pair (not per leg) via resolution_audit/resolution_diff off one representative leg from each side, since the settlement mechanism is normally shared across every leg in one event. A non-equivalent or unclear pair is NEVER suppressed, only labelled — read resolution_warning before treating spread_pp as a real cross-venue disagreement rather than a difference in contract. spread.resolution_audit carries the full underlying audit (source/timestamp/timezone/precision/evidence_standard/void_handling for both sides) and spread.resolution_source_note is the standing disclosure explaining the methodology and its "unclear" caveat. Call resolution_audit/resolution_diff directly for a specific pair of legs if you need a non-representative-sample breakdown. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.
