Prediction Market Edit History: Tracking Market Revisions
Prediction Market Edit History: Tracking Market Revisions
Prediction Market Edit History: Tracking Market Revisions
How market edits and moderator revisions work in prediction markets, what the on-chain records show, and how to build a revision history for backtests.
Prediction Market Edit History: Tracking Market Revisions
A prediction market’s edit history is the record of everything that changed about a market after it opened: its question text, its resolution rules, its status, and any moderator action taken during resolution. If you build backtests, bots or research datasets, that record decides whether your results mean anything. This guide covers where revision data comes from, what the public records show, and how to store it so a backtest sees only what was knowable at the time. It is about prediction markets, not the history of stock exchanges.
AssymetrixBuild Better Prediction Market BacktestsAssymetrix brings together prediction market data across Polymarket, Kalshi, and Limitless through one Data API for research and trading tools.Explore the Data API
TL;DR
A market is a living record, not a fixed row. Rules, status and resolution can change after trading starts, so store changes as timestamped events, never as overwrites.
Polymarket’s open resolution subgraph creates a resolution entity when a question is initialized, with a status, a dispute flag and a last-update timestamp. Those fields are the backbone of an edit history.
Moderator revisions are separately queryable through tooling built on that data, and they show when and how moderators stepped in during resolution.
For backtests, the rule is point-in-time: use the version of a market that existed at the timestamp of each trade.
Cross-venue work needs canonical market IDs, so a revision on one venue can be matched to the same event on another.
Table of Contents
Why market edits matter more than most builders expect
What the public on-chain records actually contain
Moderator revisions: the intervention layer
A schema for storing edit history
Building the history step by step
Point-in-time backtesting with revisions
Revisions and resolution data together
Cross-venue edits and canonical IDs
Our perspective
Where a data API fits
Common mistakes
Sources
Why market edits matter more than most builders expect
Most prediction market datasets arrive as a table: one row per market, with a question, an end date, an outcome and a final price. That shape hides a problem. The row you see today is the last version of the market. The market a trader faced three weeks earlier may have carried different wording, a different status, or an unresolved dispute.
If you train a model on the final version, you leak information. Suppose a clarification narrowed what “yes” meant on a given date. A model that sees the clarified text while replaying trades from before it will look smarter than it was. Prices before the clarification reflected a wider, vaguer question, and traders priced that ambiguity.
There are three kinds of edits worth separating:
Descriptive changes. The question text, description or supporting data shown to traders.
Lifecycle changes. The market moves between states such as posed, proposed, disputed and resolved.
Intervention changes. A moderator or a similar authority steps into resolution and changes the course of the outcome.
Each needs a different capture method, which is why a single “last updated” column is not an edit history.
What the public on-chain records actually contain
Polymarket publishes an open-source subgraph for market resolution. Its UMA CTF adapter handler shows how the first record is built. When a question is initialized, the handler logs the question ID and creates a MarketResolution entity keyed by that ID. It stores the creator as the author, saves the ancillary data, sets the last update timestamp from the request timestamp, marks the status as “posed”, and sets the disputed flag to false.
For anyone designing a schema, that handler teaches four things.
The question ID is the stable key. Everything about a market’s life hangs off it, so your revision table should be keyed on it too.
Ancillary data is part of the record. It carries the details that resolution depends on. Treat changes to it as rule changes, not cosmetic ones.
Status is a state machine. The entity starts as “posed” and moves from there. Each move is an event with a time, so each deserves a row.
The dispute flag starts false. A flip to true is one of the most informative events a market can have, and a history that only stores the current value loses it.
The handler shown is the initialization step only. Later handlers in the same project update the entity as the market moves through its lifecycle. When you build your own pipeline, read each handler and ask what it overwrites. Anything it overwrites is something you must snapshot yourself, because the entity will show only the latest value.
Moderator revisions: the intervention layer
The third kind of edit is the one traders worry about most. A public tool in the graph-polymarket MCP project, get_market_revisions, is described as retrieving moderator revisions for Polymarket markets, to see when and how moderators intervened in market resolution. Its input schema is small: an optional count of revisions to return and an optional question ID.
Two design lessons follow from that interface.
Query by question ID. Revisions only make sense in the context of one market. Pulling them across all markets without a key gives you a feed, which is useful for monitoring but not for analysis. When you study a particular market, always pass the ID.
Limit by count, then page. A revision list is usually short for a clean market and long for a contested one. The length itself is a signal. A market with many interventions is a different instrument from one that resolved without any.
We would not treat any single tool as the system of record. Use it to discover revisions, then confirm against the underlying on-chain or subgraph data and store your own copy with the fetch time.
A schema for storing edit history
The simplest durable design is an append-only event table next to a current-state table. Here is a minimal version.
Column | Purpose |
|---|---|
canonical_market_id | Venue-neutral key shared across venues |
venue_market_id | The venue’s own ID, such as the question ID |
event_type | description_change, status_change, dispute_opened, moderator_revision, resolved |
field_name | Which field changed, when relevant |
old_value, new_value | Raw values, not interpretations |
effective_at | When the change took effect on the venue |
observed_at | When your pipeline saw it |
source_ref | Transaction hash, subgraph entity or API response ID |
The two timestamps matter most. effective_at tells you when the change happened in the world. observed_at tells you when you could have acted on it. A backtest should gate on observed_at if it models a live bot, and on effective_at if it models an idealized trader. Mixing them up is the most common source of silent look-ahead bias we see in prediction market research.
Store raw old and new values. If you store only your own classification, such as “minor edit”, you cannot revisit the classification when your definition changes.
Building the history step by step
Snapshot the full market list on a schedule. Hash the question text, description and resolution fields. A changed hash flags an edit even when no event was emitted.
Subscribe to lifecycle events. Index the resolution contract events through a subgraph or your own listener, and write one row per state transition.
Poll revision sources for each active market. Query by question ID and diff against what you stored.
Write to the append-only table first. Update the current-state table only after the event row is committed.
Backfill carefully. For markets that closed before you started collecting, you can rebuild lifecycle events from chain history, but descriptive edits may be unrecoverable. Mark those markets as incomplete rather than assuming no edits occurred.
Version your dataset. When a backfill changes past rows, publish a new dataset version so earlier results remain reproducible.
Step five is where honesty pays. An empty edit history can mean “no edits” or “we were not watching”. Your schema should be able to tell the two apart, for instance with a coverage_start field per market.
Point-in-time backtesting with revisions
Once you have the event table, a point-in-time view is a join. For each trade at time t, select the latest revision row per field where the gating timestamp is at or before t. That gives you the market as traders saw it.
Three checks catch most mistakes.
Replay a known contested market. Confirm your view of the question at each trade matches the version live at that time.
Compare price behavior around revisions. Look at spread and volume in the window before and after a descriptive or intervention event. A strategy that appears profitable only after revisions deserves suspicion.
Exclude markets with incomplete coverage from headline results, and report them separately.
For how order flow and prices react in thin books, our piece on price impact in prediction markets pairs well with revision analysis, since revisions often land when liquidity is least forgiving. The wider structural picture is in prediction market microstructure.
Revisions and resolution data together
A revision history is most useful beside the outcome. Two questions become answerable: do markets with interventions resolve differently from clean ones, and how long do disputed markets stay unresolved? Neither can be answered from final-state tables alone.
Resolution rows need the same discipline as revisions: raw values, timestamps, a source reference. If you want a structured view of that side, see our guide to normalized prediction market resolution data. For on-chain analysis methods that feed both, the Polymarket on-chain analytics guide covers the quant workflow.
Cross-venue edits and canonical IDs
The same real-world event often trades on more than one venue, each with its own wording and its own process for changing rules. A revision on one venue can open a gap against another, and that gap is sometimes mistaken for an arbitrage. Often it is a difference in contract terms.
To reason about this you need a canonical ID that links equivalent markets, plus a field recording how their rules differ. Without it, a spread that looks like free money may be two different questions. Our arbitrage strategy guide goes through why rule comparison belongs before any trade logic, and the cross-venue data guide explains the ID approach. Regulatory context for US-regulated venues is covered in our CFTC rules guide for developers.
Our perspective
We build a cross-venue data layer, and the lesson we return to most is that a market is a sequence, not a snapshot. Our platform aggregates data from Polymarket, Kalshi and Limitless, built on roughly 1.5 terabytes of history across nearly a billion rows of trading activity. At that scale, the cost of an unrecorded change compounds: one silent rule edit contaminates every model trained across the affected window.
Our view is simple. Store events, not states. Keep two clocks. Mark what you did not observe. And keep the venue-neutral key separate from every venue’s own ID, because neutrality is what lets you compare how different venues handle the same event. We would rather a dataset say “coverage unknown” than imply a clean history it cannot prove.
— Dean
Where a data API fits
If you would rather not run the indexers, snapshot jobs and diffing yourself, our Data API gives developers unified access to cross-venue prediction market data through one integration. For Python workflows, start with the Python prediction market data guide. Pricing for the API is not published on our site, so check the Data API page for current plans.
Common mistakes
Overwriting rows in place. It is the fastest way to destroy an edit history.
Using one timestamp. Without separate effective and observed times, latency and look-ahead are indistinguishable.
Treating the dispute flag as static. It starts false for every market, and its change is the event you care about.
Assuming no revisions means a clean market. It may mean you were not collecting.
Joining on question text. Text changes. Join on IDs.
Ignoring ancillary data. Resolution depends on it, so changes there are rule changes.
FAQ
What does “market edit history” mean for a prediction market?
It is the ordered record of changes to a market after launch: wording, resolution rules, lifecycle status and moderator actions. Each change should carry a timestamp and the old and new values. Without it you can only see the market’s final form.
Where can I find moderator revisions for Polymarket markets?
The graph-polymarket MCP project exposes a tool that retrieves moderator revisions and accepts a question ID and a result count. Use it for discovery, and store your own timestamped copy of anything you rely on.
Why does edit history matter for backtesting?
Because a backtest that uses the final version of a market lets future information leak into past trades. Replaying each trade against the market as it stood at that moment removes that bias. It is the difference between a result you can trust and one that only looks good.
Can I rebuild edit history for markets that already closed?
Partly. Lifecycle events can often be reconstructed from chain history, as the resolution subgraph code suggests by tracking status and timestamps on-chain. Descriptive edits may be lost if nobody captured them, so flag those markets as incomplete.
Sources
Prediction Market Edit History: Tracking Market Revisions
A prediction market’s edit history is the record of everything that changed about a market after it opened: its question text, its resolution rules, its status, and any moderator action taken during resolution. If you build backtests, bots or research datasets, that record decides whether your results mean anything. This guide covers where revision data comes from, what the public records show, and how to store it so a backtest sees only what was knowable at the time. It is about prediction markets, not the history of stock exchanges.
AssymetrixBuild Better Prediction Market BacktestsAssymetrix brings together prediction market data across Polymarket, Kalshi, and Limitless through one Data API for research and trading tools.Explore the Data API
TL;DR
A market is a living record, not a fixed row. Rules, status and resolution can change after trading starts, so store changes as timestamped events, never as overwrites.
Polymarket’s open resolution subgraph creates a resolution entity when a question is initialized, with a status, a dispute flag and a last-update timestamp. Those fields are the backbone of an edit history.
Moderator revisions are separately queryable through tooling built on that data, and they show when and how moderators stepped in during resolution.
For backtests, the rule is point-in-time: use the version of a market that existed at the timestamp of each trade.
Cross-venue work needs canonical market IDs, so a revision on one venue can be matched to the same event on another.
Table of Contents
Why market edits matter more than most builders expect
What the public on-chain records actually contain
Moderator revisions: the intervention layer
A schema for storing edit history
Building the history step by step
Point-in-time backtesting with revisions
Revisions and resolution data together
Cross-venue edits and canonical IDs
Our perspective
Where a data API fits
Common mistakes
Sources
Why market edits matter more than most builders expect
Most prediction market datasets arrive as a table: one row per market, with a question, an end date, an outcome and a final price. That shape hides a problem. The row you see today is the last version of the market. The market a trader faced three weeks earlier may have carried different wording, a different status, or an unresolved dispute.
If you train a model on the final version, you leak information. Suppose a clarification narrowed what “yes” meant on a given date. A model that sees the clarified text while replaying trades from before it will look smarter than it was. Prices before the clarification reflected a wider, vaguer question, and traders priced that ambiguity.
There are three kinds of edits worth separating:
Descriptive changes. The question text, description or supporting data shown to traders.
Lifecycle changes. The market moves between states such as posed, proposed, disputed and resolved.
Intervention changes. A moderator or a similar authority steps into resolution and changes the course of the outcome.
Each needs a different capture method, which is why a single “last updated” column is not an edit history.
What the public on-chain records actually contain
Polymarket publishes an open-source subgraph for market resolution. Its UMA CTF adapter handler shows how the first record is built. When a question is initialized, the handler logs the question ID and creates a MarketResolution entity keyed by that ID. It stores the creator as the author, saves the ancillary data, sets the last update timestamp from the request timestamp, marks the status as “posed”, and sets the disputed flag to false.
For anyone designing a schema, that handler teaches four things.
The question ID is the stable key. Everything about a market’s life hangs off it, so your revision table should be keyed on it too.
Ancillary data is part of the record. It carries the details that resolution depends on. Treat changes to it as rule changes, not cosmetic ones.
Status is a state machine. The entity starts as “posed” and moves from there. Each move is an event with a time, so each deserves a row.
The dispute flag starts false. A flip to true is one of the most informative events a market can have, and a history that only stores the current value loses it.
The handler shown is the initialization step only. Later handlers in the same project update the entity as the market moves through its lifecycle. When you build your own pipeline, read each handler and ask what it overwrites. Anything it overwrites is something you must snapshot yourself, because the entity will show only the latest value.
Moderator revisions: the intervention layer
The third kind of edit is the one traders worry about most. A public tool in the graph-polymarket MCP project, get_market_revisions, is described as retrieving moderator revisions for Polymarket markets, to see when and how moderators intervened in market resolution. Its input schema is small: an optional count of revisions to return and an optional question ID.
Two design lessons follow from that interface.
Query by question ID. Revisions only make sense in the context of one market. Pulling them across all markets without a key gives you a feed, which is useful for monitoring but not for analysis. When you study a particular market, always pass the ID.
Limit by count, then page. A revision list is usually short for a clean market and long for a contested one. The length itself is a signal. A market with many interventions is a different instrument from one that resolved without any.
We would not treat any single tool as the system of record. Use it to discover revisions, then confirm against the underlying on-chain or subgraph data and store your own copy with the fetch time.
A schema for storing edit history
The simplest durable design is an append-only event table next to a current-state table. Here is a minimal version.
Column | Purpose |
|---|---|
canonical_market_id | Venue-neutral key shared across venues |
venue_market_id | The venue’s own ID, such as the question ID |
event_type | description_change, status_change, dispute_opened, moderator_revision, resolved |
field_name | Which field changed, when relevant |
old_value, new_value | Raw values, not interpretations |
effective_at | When the change took effect on the venue |
observed_at | When your pipeline saw it |
source_ref | Transaction hash, subgraph entity or API response ID |
The two timestamps matter most. effective_at tells you when the change happened in the world. observed_at tells you when you could have acted on it. A backtest should gate on observed_at if it models a live bot, and on effective_at if it models an idealized trader. Mixing them up is the most common source of silent look-ahead bias we see in prediction market research.
Store raw old and new values. If you store only your own classification, such as “minor edit”, you cannot revisit the classification when your definition changes.
Building the history step by step
Snapshot the full market list on a schedule. Hash the question text, description and resolution fields. A changed hash flags an edit even when no event was emitted.
Subscribe to lifecycle events. Index the resolution contract events through a subgraph or your own listener, and write one row per state transition.
Poll revision sources for each active market. Query by question ID and diff against what you stored.
Write to the append-only table first. Update the current-state table only after the event row is committed.
Backfill carefully. For markets that closed before you started collecting, you can rebuild lifecycle events from chain history, but descriptive edits may be unrecoverable. Mark those markets as incomplete rather than assuming no edits occurred.
Version your dataset. When a backfill changes past rows, publish a new dataset version so earlier results remain reproducible.
Step five is where honesty pays. An empty edit history can mean “no edits” or “we were not watching”. Your schema should be able to tell the two apart, for instance with a coverage_start field per market.
Point-in-time backtesting with revisions
Once you have the event table, a point-in-time view is a join. For each trade at time t, select the latest revision row per field where the gating timestamp is at or before t. That gives you the market as traders saw it.
Three checks catch most mistakes.
Replay a known contested market. Confirm your view of the question at each trade matches the version live at that time.
Compare price behavior around revisions. Look at spread and volume in the window before and after a descriptive or intervention event. A strategy that appears profitable only after revisions deserves suspicion.
Exclude markets with incomplete coverage from headline results, and report them separately.
For how order flow and prices react in thin books, our piece on price impact in prediction markets pairs well with revision analysis, since revisions often land when liquidity is least forgiving. The wider structural picture is in prediction market microstructure.
Revisions and resolution data together
A revision history is most useful beside the outcome. Two questions become answerable: do markets with interventions resolve differently from clean ones, and how long do disputed markets stay unresolved? Neither can be answered from final-state tables alone.
Resolution rows need the same discipline as revisions: raw values, timestamps, a source reference. If you want a structured view of that side, see our guide to normalized prediction market resolution data. For on-chain analysis methods that feed both, the Polymarket on-chain analytics guide covers the quant workflow.
Cross-venue edits and canonical IDs
The same real-world event often trades on more than one venue, each with its own wording and its own process for changing rules. A revision on one venue can open a gap against another, and that gap is sometimes mistaken for an arbitrage. Often it is a difference in contract terms.
To reason about this you need a canonical ID that links equivalent markets, plus a field recording how their rules differ. Without it, a spread that looks like free money may be two different questions. Our arbitrage strategy guide goes through why rule comparison belongs before any trade logic, and the cross-venue data guide explains the ID approach. Regulatory context for US-regulated venues is covered in our CFTC rules guide for developers.
Our perspective
We build a cross-venue data layer, and the lesson we return to most is that a market is a sequence, not a snapshot. Our platform aggregates data from Polymarket, Kalshi and Limitless, built on roughly 1.5 terabytes of history across nearly a billion rows of trading activity. At that scale, the cost of an unrecorded change compounds: one silent rule edit contaminates every model trained across the affected window.
Our view is simple. Store events, not states. Keep two clocks. Mark what you did not observe. And keep the venue-neutral key separate from every venue’s own ID, because neutrality is what lets you compare how different venues handle the same event. We would rather a dataset say “coverage unknown” than imply a clean history it cannot prove.
— Dean
Where a data API fits
If you would rather not run the indexers, snapshot jobs and diffing yourself, our Data API gives developers unified access to cross-venue prediction market data through one integration. For Python workflows, start with the Python prediction market data guide. Pricing for the API is not published on our site, so check the Data API page for current plans.
Common mistakes
Overwriting rows in place. It is the fastest way to destroy an edit history.
Using one timestamp. Without separate effective and observed times, latency and look-ahead are indistinguishable.
Treating the dispute flag as static. It starts false for every market, and its change is the event you care about.
Assuming no revisions means a clean market. It may mean you were not collecting.
Joining on question text. Text changes. Join on IDs.
Ignoring ancillary data. Resolution depends on it, so changes there are rule changes.
FAQ
What does “market edit history” mean for a prediction market?
It is the ordered record of changes to a market after launch: wording, resolution rules, lifecycle status and moderator actions. Each change should carry a timestamp and the old and new values. Without it you can only see the market’s final form.
Where can I find moderator revisions for Polymarket markets?
The graph-polymarket MCP project exposes a tool that retrieves moderator revisions and accepts a question ID and a result count. Use it for discovery, and store your own timestamped copy of anything you rely on.
Why does edit history matter for backtesting?
Because a backtest that uses the final version of a market lets future information leak into past trades. Replaying each trade against the market as it stood at that moment removes that bias. It is the difference between a result you can trust and one that only looks good.
Can I rebuild edit history for markets that already closed?
Partly. Lifecycle events can often be reconstructed from chain history, as the resolution subgraph code suggests by tracking status and timestamps on-chain. Descriptive edits may be lost if nobody captured them, so flag those markets as incomplete.
Sources
Other Blog
