Skip to main content
A relation says how two markets’ outcomes constrain each other: if this one resolves Yes, that one must too, or both cannot. This page explains the kinds of relation, what a proof needs, what is withheld, and how to read a market’s relations from the API. You need it before reading cross-venue pairs or leads, which are built on relations. Routeur only states a relation when it follows from both contracts’ structured terms and exact arithmetic. Wording is never enough, and evidence that is ambiguous or conflicting is withheld.

Kinds

From the market you asked about (GET /v1/markets/{venue}/{id}/relations): Lists of pairs and leads state the same relations from the left market’s side, with different names: subset (left implies right), superset (right implies left), and equivalent, contradicts and overlaps unchanged. Proof trails add a direction: left_implies_right, right_implies_left, both_ways, mutually_exclusive or neither.

How a relation is proven

1

Both contracts are usable

A market enters a proof only with an id, an event id, a rules hash and a payout currency, and without any invalid: issue from its source. Markets that fail are skipped, never guessed at.
2

Same variable

Both markets must measure the same real-world quantity with the same settlement scope. Within a venue that means the same event, the same custom strike terms and the same rules template with its bounds masked. Across venues it means a matched game or a matched economic release; see Cross-venue pairs.
3

Yes becomes a range

Each market’s Yes is turned into a range on that variable from its structured strike: “over 54.5 points” is the interval (54.5, ∞); “CPI rises 0.2%” on a one-decimal series is [0.2, 0.2]. Only greater, greater_or_equal, less, less_or_equal and between strikes can be read this way.
4

Compare exactly

The two ranges are compared with exact rationals, never floats. (54.5, ∞) sits inside (24.5, ∞), so “over 54.5” implies “over 24.5”. Two ranges that cannot both contain the outcome contradict; ranges that cross without containment overlap.
Two more sources add relations without a strike:
  • One-winner events. When the venue asserts that at most one market in an event can resolve Yes, every pair in the event contradicts, with the evidence source event asserts mutually exclusive markets.
  • Matched games and releases across venues. A proven match lets the two venues’ ranges be compared as if they were on one variable; see Cross-venue pairs.

What is withheld

Nothing is inferred from a title. Two markets with identical wording and no structured terms in common are not related.

Reading a market’s relations

Cross-venue relations come first. Each entry carries: Every market also carries counts, so you can see at a glance how connected it is:

Proof, versions and reproduction

A relation is proven against specific contract versions, identified by each market’s rules_hash. When a venue changes a market’s terms, the market is re-read as a new version and its relations are proven again. GET /v1/relations/{left_venue}/{left_id}/{right_venue}/{right_id} returns the full proof trail for a pair, with the ranges, the ordered steps, and reproduced, which says whether rebuilding the graph from the stored versions today still yields the stored relation. See Proof trail.
A relation is a constraint on prices. If a market implies another, its Yes should never cost more than the other’s Yes. When it does, there is a lead.
  • Cross-venue pairs: which games and releases are matched across Kalshi and Polymarket.
  • Proof trail: every step behind one relation.
  • Leads: purchases that a relation guarantees.
  • Rules: contract versions and how terms change.
  • Live stream: new relations pushed as each graph run finishes.