A prediction market resolves. The page shows a winner. Six weeks later you go back to check something, and the page still shows a winner — but is it the same winner it showed on resolution day? Did the recorded outcome ever change? Was it ever contested? On almost every prediction market surface, you cannot answer those questions, because the resolution is a single mutable field that shows you today's value and keeps no memory of its own past. Settlement, of all things, is treated as a fact with no history.
CoinRithm aggregates prediction markets across venues and, since mid-2026, keeps something most surfaces don't: an append-only settlement provenance ledger — a permanent, per-event record of how a market's outcome was decided, revised, and disputed over time. This article explains what that ledger is and why "keeping the receipts on a resolution" is a different, more concrete promise than the broader question of whether you can trust a venue's settlement at all. For that broader framework — who decides, on what evidence, how contestable — read can you trust prediction market settlement?; this piece is about the data structure underneath it.
TL;DR
- Most prediction-market surfaces store a resolution as one mutable field with no history — so a changed or contested outcome leaves no trace.
- CoinRithm records settlement as an append-only ledger: each observation of the resolved outcome is a permanent entry, and revisions supersede rather than overwrite.
- Every closed event's ledger exposes a standing outcome, an observation count, a revision count, a method, and a dispute state (undisputed, disputed, or dispute-resolved).
- Because entries are never deleted, a resolution that later flips is visible as a revision, not silently rewritten — the record shows the whole path, not just the endpoint.
- It sits beside the per-event settlement-eligibility and trust-tone signals, so "has this actually, verifiably paid out?" is answerable at a glance.
- Honest scope: the ledger covers events resolved after it shipped, and today most events show a single, clean, undisputed decision — its value is the audit trail it keeps for the day one doesn't.
The problem: settlement with no memory
Everything before resolution has some notion of history. Prices tick and leave a chart. Volume accrues. Order books move. But the moment that actually decides who was right — the settlement — is, on most surfaces, a single value: outcome = Yes. It shows you the current state and nothing about how it got there. If it was recorded once and never touched, fine. If it was recorded, then quietly changed a week later after a dispute, the field looks identical either way. The absence of history is the problem: you cannot distinguish a clean, first-time resolution from a contested one that flipped, because the surface remembers only the last thing written.
This matters more than it first appears, because settlement is exactly where trust is spent rather than merely promised. A market can trade beautifully for months and then resolve ambiguously, late, or contested — and if the record of that resolution has no memory, you are left arguing from screenshots and recollection about what the outcome "originally" said. The failure isn't only that a resolution can be wrong. It's that a resolution can change and leave no evidence that it ever did.
The mechanics of how different venues arrive at a resolution in the first place are their own subject — oracles, exchange rules, graders — and we cover them in how prediction markets resolve. This article is about what happens to that resolution as data once it exists: whether it is kept as a fact with a past, or a field without one.
What an append-only ledger changes
The fix is a well-understood idea borrowed from accounting and version control: never overwrite; only append. Instead of a single outcome field, each event carries a ledger of settlement decisions. When the aggregator observes the resolved outcome from a provider, it writes an entry. If the outcome is later revised, it does not edit the old entry — it writes a new one that explicitly supersedes the previous, and the previous is marked as reversed-by the new one. Nothing is deleted. The chain of "what the outcome was recorded as, and when" is preserved end to end.
From that append-only history, a few honest summary numbers fall out naturally, and CoinRithm surfaces them directly on the event page:
- Standing outcome — the current adjudicated result (the entry that nothing has superseded), with the timestamp it was recorded.
- Observations — how many times the resolved outcome has been asserted for this event. A stable resolution accumulates confirmations; a shaky one shows churn.
- Revisions — how many times the standing outcome actually changed. Zero is the healthy default; anything above zero is a flag you can now see rather than one hidden from you.
- Method — how the decision was reached (for example, a resolution-watch pass over provider data), so the provenance of the provenance is itself recorded.
- Dispute state — whether the current decision is undisputed, disputed, or a resolved dispute, shown as an explicit badge rather than left to inference.
None of these require you to trust a narrative. They are computed from a record that cannot be quietly rewritten, and when there is more than one decision in the history, the event page renders the full timeline — each recorded outcome, its time, its dispute state, and whether it is the current standing entry or a superseded one.
Reading the ledger on an event page
On a closed event that has a recorded ledger, the settlement provenance section is compact and blunt. It leads with the standing outcome and when it was recorded, then shows the observation and revision counts and the method, with a dispute badge if the current decision is or was contested. If the outcome was ever revised, a short history list appears beneath, walking the decisions in order and marking each as current or superseded.
The everyday case, honestly, is undramatic: one observation, zero revisions, undisputed — a market that resolved cleanly, once, the way it should. That is not a weakness of the feature; it is what a healthy resolution looks like, and showing it plainly is itself the point. The value is asymmetric. When resolution goes smoothly, the ledger is a quiet confirmation. When it doesn't — a late correction, a contested call, an outcome that flips — the ledger is the only thing standing between you and a settlement you cannot reconstruct. You keep the receipts precisely so that the rare bad day is auditable instead of a matter of memory.
How it connects to agent decisions
The settlement ledger is not an isolated feature. It is the resolution-side anchor of a larger, deliberately verifiable evaluation layer. When a CoinRithm Arena AI agent takes a position on a market, that decision is recorded as an immutable, hashed artifact — the subject of how to verify an AI agent's track record. When the market later settles, the agent's artifact picks up a settlement stamp that points back to exactly this ledger. So the full chain is auditable end to end: what the agent decided and when (fingerprinted), and how the event it bet on was ultimately resolved (append-only). Neither half trusts the other blindly; both keep their own tamper-evident record.
That closes a loop that most agent leaderboards leave open. A win is only meaningful if the settlement behind it is real and unchanged — and here the settlement behind an agent's win is a ledger entry with a history, not a mutable field someone could have flipped after the fact.
Where it fits with eligibility and trust tone
Provenance answers "what was recorded, and did it change." Two neighboring signals answer the closely related questions of "is this outcome trustworthy enough to score on" and "has it verifiably paid out," and CoinRithm keeps them distinct on purpose:
- Settlement eligibility. Every event moves through a defined lifecycle — open, closed, awaiting resolution, resolved — and carries flags for whether its outcome and settlement timing are provider-verified and whether it is eligible to count toward calibration. A market whose ledger says "resolved, undisputed, provider-verified" is a market whose result can be trusted enough to grade an agent or a venue on. This eligibility gate is the backbone of our honest accuracy work in how accurate are prediction markets.
- Per-event trust tone. Alongside the ledger, event pages show a resolution trust tone — verified, limited, awaiting, or unverified — that states plainly what CoinRithm can actually confirm about a settlement, rather than what a venue claims. That labeling is covered in the trust framework, and the provenance ledger is the concrete evidence beneath the label.
Put together: the trust tone tells you the confidence, the eligibility flags tell you whether it can be scored, and the provenance ledger shows you the underlying record those judgments are computed from. Layers, not a single vague "resolved."
The honest limits
This is a real, running data structure, and it is also young — worth being direct about both.
First, scope. The ledger records provider resolutions from the point the feature shipped forward; events resolved before it existed have no ledger, and the event page simply omits the section rather than inventing a backfilled history. There is no pretending a market from three months ago has an audit trail it never had. The honest statement is "from here on," not "always."
Second, the ledger records observations, not adjudication. CoinRithm does not resolve markets, grade outcomes, or arbitrate disputes — it observes what providers report and keeps an append-only, tamper-evident record of those observations. If a venue itself makes a bad call, the ledger will faithfully record that call and any later correction; what it guarantees is that the record cannot be silently rewritten, not that the underlying resolution was correct. That distinction is the same one that runs through the whole settlement-trust framework: better information reduces surprise, but no ledger can force a venue to have decided rightly. What it can do — and does — is make sure that whatever was decided is remembered honestly, in full, and by more than one party's memory.
FAQ
What is settlement provenance in a prediction market?
It is the recorded history of how a market's outcome was decided — not just the final result, but each observation of that result, any revisions, the method used, and whether it was disputed. CoinRithm keeps this as an append-only ledger per closed event, so a resolution is stored as a fact with a past rather than a single mutable field that forgets how it got to its current value.
How is an append-only settlement ledger different from a normal resolution field?
A normal resolution field shows only its current value; if the outcome changes, the old value is overwritten and gone. An append-only ledger never overwrites — a revised outcome is written as a new entry that supersedes the previous one, and nothing is deleted. That means a resolution that later flips is visible as a revision in the record, instead of vanishing without a trace.
What do "observations" and "revisions" mean on the ledger?
Observations count how many times the resolved outcome has been asserted for an event — repeated confirmations of a stable result. Revisions count how many times the standing outcome actually changed. A clean resolution typically shows several observations and zero revisions; a nonzero revision count is a flag that the recorded outcome moved, which the ledger makes visible rather than hiding.
Does the settlement ledger mean CoinRithm resolves markets?
No. CoinRithm does not decide, grade, or arbitrate outcomes — it observes what each venue's provider reports and records those observations in a tamper-evident, append-only ledger. If a venue makes and then corrects a call, the ledger faithfully records both. It guarantees the honesty of the record, not the correctness of the venue's underlying decision.
Why do most events show just one undisputed decision?
Because most resolutions are clean: the outcome is recorded once, from provider data, and never changes. A single undisputed observation with zero revisions is exactly what a healthy settlement looks like. The ledger's value is asymmetric — it is quiet confirmation on the normal days and the only reliable audit trail on the rare day a resolution is late, corrected, or contested.
Does every prediction market event on CoinRithm have a provenance ledger?
Not yet. The ledger covers events resolved after the feature shipped in mid-2026; events resolved earlier simply don't display the section rather than showing a fabricated history. Over time, as more markets resolve, the coverage grows — and the record is honest about the boundary rather than backfilling a trail that never existed.
