Skip to main content
A market is decided by its rules, and venues change them. Routeur keeps the rule text of every market version it has ever recorded, from the first day it was listed, along with the rulebooks that govern it from above: a Kalshi series’ contract terms and settlement sources, a Kalshi event’s settlement terms, a Polymarket market’s resolution metadata. Every change is an entry in a ledger, with a diff, and a rule_change event on the live stream.

​
Versions and the rules hash

Each market has a rules_hash: a hash over the terms that decide it, which the venue’s listing carries. When any of those terms changes, the hash changes and Routeur records a new contract version. Relations are proven between contract versions, not markets, so a proof names the hashes it holds for (see Proof trail). A version records the rule text, title, outcome labels, event, structured strike, open and close times, game start and, on Polymarket, the outcome tokens. Two versions are compared field by field; the fields that differ are named in changed_fields: An empty changed_fields on a later version means the venue changed something the hash covers but none of the recorded fields show, such as an expiration or settlement timestamp; the summary says so.

​
Rulebooks above markets

Some terms are not written on the market. Routeur records them as rulebooks, versioned by the hash of their settlement fields alone, so a rulebook version changes only when the terms do and not when a title or artwork does: Every rulebook version carries the venue’s fields verbatim in fields, the settlement_sources read from them (name and link), and a source_url: the venue’s own page or document for these terms, kept only when it is an absolute https link. A Kalshi series rulebook names a contract terms document, the PDF Kalshi publishes on its own asset host. A separate job fetches each document at most once a day, extracts its text and stores each distinct content once, so document on a series version carries the text in force for that version, its content_hash, when it was fetched, the last fetch error if any, and a diff from the previous version’s text. Only PDFs on assets.kalshi.com are fetched. Each contract version is linked to the rulebook versions that were in force while it was seen, so a market’s rules can be read as they stood for any version.

​
The change ledger

Every change to a market’s terms is one ledger entry, with a scope: Each entry has changed_at, changed_fields and a one-sentence summary in plain words, such as Close time moved from 2026-09-17T19:00:00Z to 2026-09-17T20:20:00Z; game start moved from 2026-09-17T13:00:00Z to 2026-09-17T14:20:00Z. The same change seen again is not recorded twice. When a rulebook changes at the same moment as the contract itself, the ledger has one contract entry and the version lists the rulebook under rulebooks_changed, with the hash it replaced; there is no separate rulebook entry, because the rulebook did not change under an unchanged contract. Every ledger entry is also a rule_change event on the rules topic of /v1/stream, with the same fields plus venue, market_id, title and rules_path, the endpoint to read the versions and diffs from.

​
A market’s rules

Works for any market ever recorded, listed or not. 404 market_not_found means no contract terms were ever recorded for it.
Four versions in three days: the venue moved the match twice, then changed a term the recorded fields do not show at the same moment its resolution metadata moved from no UMA status to proposed. That rulebook change rides on the contract version’s rulebooks_changed rather than getting its own ledger entry, because the contract changed with it. Hashes are shortened here; the API returns them in full.
To know whether a market’s terms changed since you took a position, compare the rules_hash you traded on with the current one, then read changes after your trade’s time. A rule_change stream event does the same without polling.

​
A rulebook’s versions

kind is series or event on Kalshi and market on Polymarket. The response lists every recorded version, oldest first, and markets, how many markets were ever recorded under the rulebook. 404 rulebook_not_found means none has been recorded under that venue, kind and id. A Kalshi event rulebook as recorded (one version, fields trimmed):
A Kalshi series version adds source_url (the contract terms PDF) and document with the PDF’s extracted text, content_hash, fetched_at and, from the second version on, a diff of the text. When the last fetch failed, document.error says why and text is the last content fetched successfully, if any.

​
What is not there yet

  • Clause extraction. The rule text is stored and diffed as text. Settlement sources are read from structured fields, not from the prose, and no clause (settlement time, tie rule, cancellation policy) is extracted as a field yet.
  • Pair comparison. A proof says why two markets are related from their structured terms; there is no side-by-side comparison of two markets’ rule texts yet. Both are planned.
  • Proof trail: how a relation names the contract versions it holds for.
  • Live stream: the rules topic and rule_change events.
  • Events and markets: where rules_hash and the structured strike appear on every market.