Predict Market Desk Connect to Dexsport
DexsportMarketsMechanics Connect to Dexsport

Home › Mechanics › Oracles and market resolution

Oracles and how markets resolve

What resolution means

Resolution is the process that turns an open market into a settled one. A market poses a question — will a particular team win, will a price close above a threshold, will a fighter make weight — and resolution is the act of deciding, definitively and irreversibly, which outcome occurred. Until that happens, every position in the market is provisional. Once it happens, the market's ledger is fixed: winning shares pay out, losing shares expire worthless, and the collateral locked in the contract is released. For a bettor, resolution is the moment the wager stops being a probability and becomes a fact.

It helps to separate two things that are often blurred together. The first is the real-world event: the match ended, the vote was certified, the temperature was recorded. The second is the market's official determination of that event. These are usually the same, but not always. A market can resolve in a way that contradicts what most observers believe actually happened, because the resolution follows the rules written into the contract rather than the general mood. This is not a bug. A market that paid out on vibes would be worthless, because nobody could predict what it would do. The whole point of a resolution rule is that it is fixed in advance, so participants can price the outcome before the event.

The resolution rule is therefore part of the product, not an afterthought. It specifies the question, the source or sources that will be consulted, the deadline, and what happens if the source is unavailable or ambiguous. Two markets can look identical on the surface — both asking whether a bill passed — and resolve differently because one defines passage as a vote in the lower house and the other as royal assent. Careful readers learn to read the resolution criteria as closely as they read the headline question. The headline is marketing; the criteria are the contract.

There is also the question of timing. Resolution is not always immediate. Some markets resolve the moment a whistle blows; others wait for an official result to be certified, a data series to be revised, or a challenge window to elapse. That delay is deliberate. Rushing to settle on a provisional number invites disputes and creates an incentive to trade on information that later turns out to be wrong. A short, well-defined waiting period is usually a sign of a thoughtful market, not a slow one.

Finally, resolution is where the abstract idea of a market meets the messy reality of the world. Events get cancelled. Sources disagree. A player is substituted in the first minute and the market's rule never anticipated it. The quality of a market is measured less by how it handles the clean cases — those are easy — and more by how it handles the ambiguous ones. The rest of this guide is about the machinery that makes those decisions, and where it can go wrong.

Who reports the outcome

In principle, anyone can report an outcome; in practice, a market needs a designated reporter whose word is authoritative. The simplest design is a single named source: the official league website, a specific exchange's closing price, a government statistics release. The market's rules say, in effect, "we will look at this one thing, and whatever it says is the answer." This is cheap, fast, and easy to understand. Its weakness is equally obvious. If that source is wrong, late, or manipulated, the market inherits the flaw.

A step up from a single source is a small committee or a designated resolver — often the platform itself, or a panel of people with relevant expertise. The committee can weigh context that a single feed cannot: it can notice that a result was later overturned on appeal, or that a data provider published a correction. The trade-off is discretion. Once you allow a human to interpret, you have introduced the possibility of inconsistent or self-interested interpretation, and you have made the outcome harder to predict in advance. Bettors dislike uncertainty about the resolver almost as much as uncertainty about the event.

The third model is decentralised reporting, where a broad set of token-holders or staked participants vote on the outcome. The appeal is that no single party controls the answer, and that lying is meant to be expensive because honest reporters are rewarded and dishonest ones are penalised. The cost is complexity and, at times, slowness. A decentralised oracle has to coordinate many participants, define what counts as consensus, and handle the case where the crowd is simply wrong or apathetic. It also has to defend against participants who vote strategically rather than honestly.

In practice, most sports and event markets sit somewhere between these poles. A platform might use an official feed for the primary result, a fallback source if the first is unavailable, and a human or committee process for genuinely contested cases. This layering is sensible, but it means the resolution path is not always obvious from the headline. A careful reader wants to know not just who reports the outcome, but who reports it when the first reporter fails, and who adjudicates when two reporters disagree.

There is a further distinction between reporting and verifying. A reporter supplies a claim; a verifier checks it against evidence. Some systems collapse the two roles, trusting the reporter's claim directly. Others separate them, requiring independent confirmation before settlement. Separation is more robust but slower and more expensive. The design choice reflects how much the market values speed against certainty, and there is no universally correct answer — only a trade-off that should be stated plainly in the rules.

Oracle designs compared

The word oracle covers a wide range of mechanisms, and comparing them is really comparing different answers to the same problem: how do you get trustworthy information into a system that cannot observe the world for itself? The first axis is centralisation. A centralised oracle is one operator or feed. It is fast, cheap, and simple, and for many markets it is entirely adequate. Its risk is concentrated: a single point of failure, a single point of capture. If the operator is compromised, bribed, or simply mistaken, there is no internal check.

The second axis is the source of truth. Some oracles read objective, machine-verifiable data — a price feed, a timestamp, a final score from an official API. These are relatively easy to resolve because the answer is a number or a discrete result that can be fetched and compared. Others require human judgement: did a statement count as an admission, was an event "cancelled" or merely "postponed", did a fighter "win" if the bout was stopped on a cut. Judgement-based markets are where oracle design matters most, because the answer cannot simply be read off a feed.

The third axis is the incentive structure. In a well-designed decentralised oracle, participants stake value on their report. If the report is accepted as correct, honest reporters earn a reward; if it is rejected, dishonest reporters lose their stake. The idea is to make truth-telling the profitable strategy. This works when the stake is large relative to the value at risk in the market, and when the set of reporters is broad enough that collusion is hard. It works less well when the market is small, the reporters are few, or the outcome is genuinely ambiguous and reasonable people disagree.

A fourth axis is finality. Some oracles resolve once and for all; others allow a challenge and a re-resolution. Immediate finality is clean but unforgiving — a wrong call stands. Challengeable resolution is safer but slower, and it opens a window during which the market is unresolved and positions are frozen. Most robust systems accept the delay, because the alternative is a market that can be settled wrongly with no recourse.

Comparing designs, the pattern that emerges is that no single mechanism dominates. Centralised oracles win on speed and clarity; decentralised ones win on censorship resistance and, in principle, on integrity. Feed-based oracles are excellent for objective data and poor for judgement calls. The best practical systems tend to be hybrid: objective data from a trusted feed where possible, a decentralised or committee process for contested or subjective cases, and a clear rule about which applies when. When you evaluate a market, ask which design it uses and whether that design matches the kind of question being asked.

Disputes and challenge windows

A challenge window is a defined period after a proposed resolution during which the outcome can be contested. Instead of settling instantly, the market announces a provisional result and waits. If nobody objects within the window, the result becomes final. If someone does object, the dispute goes to a higher authority — a committee, a token vote, an arbitration process — which decides the matter. The window exists because provisional results are sometimes wrong, and because giving people a chance to correct them is cheaper than unwinding a settled market.

The length of the window is a deliberate trade-off. A short window settles quickly and keeps capital moving, but it may not give a distant or busy participant time to notice an error and object. A long window is safer but ties up funds and delays payouts, which is frustrating for winners and costly for anyone who needs the liquidity. Different markets choose differently depending on the stakes and the likelihood of dispute. High-value, judgement-heavy markets tend to have longer windows; routine, feed-driven markets can settle almost immediately.

Disputes need a cost, or they become a denial-of-service tool. If objecting is free, anyone can stall any market indefinitely by filing spurious challenges. Most systems therefore require a challenger to post a bond, which is returned if the challenge succeeds and forfeited if it fails. This prices frivolous disputes while keeping genuine ones affordable. The size of the bond is another trade-off: too small and it does not deter abuse, too large and it deters legitimate challenges from ordinary participants.

There is also the question of who decides a dispute and how. A committee can deliberate and explain its reasoning, which is valuable when the case is genuinely novel. A token vote is more resistant to capture but can be captured by a large holder, and voters may lack the context to judge a nuanced case. Some systems escalate: a first challenge goes to a panel, a further appeal goes to a broader vote. Each layer adds cost and delay but also adds a check on the layer below. The design should tell you, in advance, which layer applies and what standard of evidence it uses.

Finally, disputes raise the question of finality versus fairness. Once a result is final, it should stay final; a market that can be reopened indefinitely is not a market. But a result that is clearly wrong and cannot be corrected is also a failure. The challenge window is the compromise: a bounded period in which correction is possible, followed by genuine finality. The key is that the boundary is known in advance. If you cannot tell from the rules when a result becomes irreversible, you cannot reliably price the risk of a dispute.

Manipulation and edge cases

Manipulation is the attempt to influence a market's resolution rather than its underlying event. The most direct form is attacking the oracle: bribing a reporter, compromising a feed, or acquiring enough voting power to force a false result. This is most attractive when the value at stake in the market exceeds the cost of corrupting the oracle. A large market resolved by a small, cheap-to-influence reporter is an invitation. Robust designs make the cost of corruption exceed the profit from it, which is why stake sizes and reporter diversity matter.

A subtler form is influencing the source itself. If a market resolves on a specific index or feed, someone with the ability to move that index at the resolution moment can profit without predicting anything. This is why markets tied to thin or manipulable reference prices are risky, and why using a broad, liquid, hard-to-move source is safer. The same logic applies to events: a market on a minor statistic that a participant can affect directly is more exposed than one on a result nobody can engineer.

Edge cases are where rules earn their keep. Consider a match abandoned after a certain point, or a result later overturned on appeal. Does the market resolve on the result at the final whistle or on the eventual official outcome? Both are defensible, but they are different markets, and the rule must say which. Consider a player who is named in the starting line-up, withdraws during the warm-up, and is replaced. A market on "will X play" needs to define whether playing means being on the pitch, being in the squad, or being named. These are not hypotheticals; they recur, and vague rules produce disputes.

Another recurring edge case is the source that changes its story. A data provider publishes a figure, then revises it. An official body initially declares one winner and later corrects the record. The rule should specify whether the market follows the first publication or the final, corrected version, and how long it waits. Without that, the market is at the mercy of timing, and two participants reading the same rule can reasonably expect different payouts.

There is also the problem of the oracle being right but the market being unfair. A resolution can be technically correct and still leave participants feeling cheated, because the rule was poorly drafted. When that happens repeatedly, participants leave, and the market's liquidity dries up. Good operators treat ambiguous rules as a defect to be fixed, not as a technicality to be defended. For a bettor, the lesson is to read the criteria and, where a rule is genuinely unclear, to assume the worst case rather than the most intuitive reading.

Trusting a resolution source

Trust in a resolution source is not binary. You are not choosing between trusting it completely and trusting it not at all; you are assessing how much damage a failure would do and how likely a failure is. A source that is objective, widely observed, and expensive to manipulate deserves more trust than one that is private, narrow, and cheap to influence. The relevant question is not "is this source honest?" but "what would it cost someone to make this source lie, and what would they gain?"

Track record matters, but it is not everything. A source with a long history of accurate reporting is reassuring, yet past accuracy does not guarantee future accuracy, and a source can be reliable for years and then fail once at the worst moment. More useful than a general reputation is a specific answer to specific questions: How does this source handle corrections? Does it publish its methodology? Is it independent of the parties who stand to gain from a particular outcome? Does it have competitors that would catch and publicise an error? A source that is checked by others is safer than one that is not.

Redundancy is the most practical form of trust. If a market resolves on a single feed, a single failure settles the market wrongly. If it resolves on the agreement of two or three independent sources, a single failure is caught. This is why fallback sources and cross-checks appear in well-drafted rules, and why their absence is a warning sign. Redundancy costs speed and complexity, but it converts a single point of failure into a manageable risk.

For decentralised oracles, trust is distributed but not eliminated. You are trusting that the incentive design actually aligns reporters with honesty, that the stake is large enough to matter, and that the set of reporters is not quietly controlled by a small group. These are empirical questions, and the answers can change as a system grows or as its token distribution shifts. A decentralised oracle is not automatically more trustworthy than a centralised one; it is trustworthy to the extent that its incentives and its participant base hold up under pressure.

The practical conclusion for anyone using these markets is to treat the resolution source as part of the bet. Before committing, identify who reports the outcome, what happens if they fail or disagree, how long the challenge window is, and who decides a dispute. If those answers are unclear, the market carries a hidden risk that is not reflected in the price. Where a market is well specified, the resolution risk is small and the odds mostly reflect the event. Where it is vague, the odds may look attractive for reasons that have nothing to do with the event at all. None of this is legal advice, and gambling rules differ by jurisdiction; if you are in the Netherlands, check what applies to you. Whatever you use, bet only what you can afford to lose, treat it as entertainment rather than income, and if gambling stops being fun, stop — help is available from recognised support services, and you must be 18 or over to take part.

This guide was researched, written and fact-checked by the Predict Market Desk editorial desk before publication. Last reviewed 13.10.2026. Spotted something wrong? Tell us.

Connect to Dexsport