If you spend enough time around prediction-market builders, you'll notice that the conversations split cleanly into two camps: the front of the stack (matching, UX, liquidity) and the back of the stack (resolution, settlement, oracles). The front-of-stack problems are solvable with engineering hours and capital. The back-of-stack problems are solvable with cryptoeconomic design — and they're where prediction-market platforms actually live or die.
This post is for operators and engineers who already understand the business case (start with our market analysis if you don't) and want to know how the settlement layer actually works.
That number is the headline result of about six years of optimistic-oracle design: the overwhelming majority of resolutions never need a vote, because the system is designed to make honest proposers cheaper than dishonest ones. Below is how that's achieved, where it breaks, and what it implies for any operator running real volume on top of it.
The settlement problem, stated cleanly
Every prediction-market contract has a single job at the end of its life: emit a payoff to the side that was right. To do that, the contract has to know what actually happened. The challenge is that a smart contract has no eyes — it cannot watch CNN, read a CPI release, or check a sports score. It depends on an external mechanism to tell it the truth.
That external mechanism is the oracle. Every prediction market sits on top of one. The oracle is the trust assumption of the entire system. It is the reason "the contracts are audited by OpenZeppelin" matters less than people think — the contracts can be flawless and the platform still fails if the oracle is gameable.
There are three properties any oracle in this context has to deliver:
- Correctness. The reported outcome must match reality.
- Liveness. The outcome must be reported within a reasonable window of resolution; markets cannot hang indefinitely.
- Censorship resistance. No single actor can prevent a true outcome from being recorded.
The trade-off space across these three properties is the entire field of oracle design.
Centralised resolution: simple, fast, fragile
The oldest and simplest approach is for the operator (or a designated market-integrity team) to resolve markets directly. Kalshi does this: the exchange consults pre-published data sources, applies its documented resolution policy, and posts the outcome.
This works well when:
- The data source is unambiguous and available (e.g., the BLS CPI release).
- The operator has a regulated identity (in Kalshi's case, the CFTC).
- The resolution policy is published in advance and doesn't move.
It fails when:
- The data source is ambiguous or contested.
- The operator has a financial interest in the outcome.
- The resolution policy is rewritten retroactively.
Centralised resolution is appropriate for highly regulated, narrow contract spaces. It is structurally inappropriate for the long tail of markets that drive most prediction-market volume — sports edge cases, geopolitical events, anything where the underlying fact is interpreted rather than measured.
The optimistic oracle pattern
The optimistic oracle, popularised by UMA in 2020, replaces a single trusted resolver with a game-theoretic assertion-and-challenge process. The structure is intuitive once you see it.
Step 1. Proposal. Anyone can propose an outcome to a market by
posting a bond. "I claim the contract on Will the Fed cut rates in July? resolves YES." The proposer attaches collateral (typically a
few hundred dollars in USDC) and submits.
Step 2. Challenge window. A timer starts — usually 2 hours for real-money markets, longer for higher-stakes markets. During this window, anyone can dispute the proposal by posting their own bond.
Step 3. Two paths.
- No challenge. If nobody disputes within the challenge window, the proposed outcome is final. The proposer's bond is returned, and a small reward is paid out for the work of proposing.
- Challenge. If anyone disputes (with bond), the question escalates to a vote of UMA token holders. The vote settles which side was right. The losing side's bond is paid to the winning side and to the protocol. The winning side recovers their bond and collects a reward.
The economics are deliberately asymmetric. A truthful proposer expects no challenge — because everyone watching can see the outcome is true, and challenging a true outcome means losing your bond. A truthful disputer challenges only when the proposed outcome is visibly wrong — because a frivolous dispute also costs the bond.
The result, in practice, is that almost every resolution settles in the optimistic path. The dispute path exists primarily as a credible threat that keeps the optimistic path honest.
How disputes actually escalate
The interesting failure mode is the dispute itself. When a real disagreement reaches a vote, the protocol has to handle three sub-problems:
- Vote integrity. UMA's voting uses commit-reveal so voters can't copy each other's choices. Voters commit a hashed vote, then reveal later. This prevents trivial collusion.
- Schelling-point resolution. Voters are paid for voting with the majority of other honest voters. The protocol assumes a focal point (the "obvious" answer) emerges naturally for any well-specified contract. This works exactly as well as the contract specification — vague contracts get vague resolutions.
- Final-arbiter escalation. For very high-stakes disputes, UMA has a multi-round escalation: if a vote is ambiguous, it can re-run with a higher quorum and a longer voting window. This is used in practice maybe a handful of times per year.
The protocol-level cost of a disputed market is high. The disputer and the proposer both have capital locked. UMA voters spend real attention. A clean platform avoids disputes by writing markets that don't generate them. The discipline of contract specification — which sounds like a paperwork problem — is actually the most important operational lever a venue has.
Why most platforms get this wrong
The single most common mistake we see in operator builds is treating resolution as a back-office concern that can be handled with "we'll just reconcile manually." That works at 50 markets a week and breaks at 5,000.
Three failure modes show up consistently:
The vague-contract failure. The market is written ambiguously (e.g., "Will the conflict end in 2026?" with no definition of "end"). Two outcomes are defensibly true. The market goes to dispute, the dispute drags, traders lose confidence, and the operator's reputation takes a hit that doesn't reverse.
The data-source-moves failure. The market specifies a data source that gets renamed, restructured, or paywalled mid-life. The contract points at a source that no longer exists, and resolution has to be reconstructed manually.
The interest-conflict failure. The operator (or someone close to the operator) has a position in the market. When resolution is opaque, this becomes a public scandal regardless of what the operator actually did. The optics alone destroy the platform's credibility.
The cleanest defence against all three is to design the contract such that the resolution path doesn't depend on the operator's discretion. The optimistic-oracle pattern is structurally well-suited to this: the operator is not the resolver, the data source is named and locked at market creation, and the dispute mechanism is public.
| Failure mode | Centralised resolver | Optimistic oracle |
|---|---|---|
| Vague contract | High exposure | Disputes; correctly identifies bad spec |
| Data source moves | Manual reconcile | Replay through dispute |
| Operator interest conflict | Existential | Structurally separated |
| Cost of malicious resolution | Trust collapse | Bond + vote rewrite |
| Speed for trivial markets | Faster | Same (no dispute path) |
What Kuest actually does at the settlement layer
Kuest's approach inherits the optimistic-oracle pattern from Polymarket's production architecture for multi-operator deployment. In practice:
- UMA-based dispute flow. Resolution proposals follow UMA's optimistic-oracle mechanics instead of ad-hoc operator decisions.
- Rules and source metadata at market level. Each market carries explicit rules and an optional resolution source URL visible in the event rules panel.
- Pre-publish quality checks in admin flow. The event-creation workflow checks mandatory fields and validates resolution-source URL format before launch.
- Dispute visibility in platform data. Market payloads expose dispute state fields (for example whether a resolution was disputed), so operators can monitor resolution health.
The point of all of this is to make resolution boring. A platform where resolution is the most exciting thing happening is a platform that's about to lose users.
How dispute economics actually behave under load
A subtlety worth dwelling on: optimistic-oracle dispute economics are not just theoretical. They've been stress-tested by real adversarial volume, and the data tells you something useful about where the model holds and where it gets pressure.
The largest disputed markets on Polymarket since 2023 have shared a common shape. They cluster around contracts where the underlying event is genuinely contested in the real world — not where the contract was specified badly, but where reasonable observers disagreed about what happened. A geopolitical event with two plausible interpretations, an electoral event with overlapping counting deadlines, a sports event with a post-game review changing the result hours later. The dispute mechanism handles these by forcing the question to a vote, but the vote itself reflects a genuine ambiguity in the world. The protocol does as well as a protocol can; it cannot resolve facts that the world hasn't yet resolved.
What this means in practice for an operator: the dispute path is not an "exception" that you should treat as a system failure. It's a designed-in mechanism for handling the irreducible ambiguity of real-world events. Markets that go to dispute and then settle correctly are the system working as intended, not the system breaking.
The operator-side discipline is to keep the dispute rate within the range that's structurally explainable. If your venue's dispute rate is 0.1–0.3% (in line with Polymarket's long-run rate), you're probably writing markets well. If you're seeing 1%+, the markets themselves are under-specified and you have a contract-design problem, not a settlement-layer problem.
The dispute model also has known soft edges that mature operators plan around. Disputed markets can hang in voting limbo for several days while UMA voters resolve, which is a UX problem if a trader has capital tied up in the position and needs the cash for unrelated reasons. Most operators address this by capping the maximum dispute window for non-critical markets and accepting a small protocol-fee overhead in exchange for the predictability.
What this means if you're operating
Three implications fall out of this directly for any operator running on Kuest or evaluating the protocol against alternatives.
- Spend more time than you think on contract specification. Every ambiguity in the market wording creates a resolution exposure. The operators we work with treat market specification as a senior role, not a junior one.
- Inherit a settlement model, don't build one. The cost of a home-grown oracle is enormous, the failure modes are catastrophic, and the alternative — using UMA-style resolution as a service — is mature, audited, and battle-tested. There is essentially no case for building a custom oracle in 2026 unless oracle design is your primary product.
- Watch the dispute rate as a leading indicator. A dispute rate above ~0.5% on a venue is a signal that contract specifications are getting loose. It precedes user-trust degradation by several weeks. Most operators don't watch this metric; they should.
The settlement layer is the part of the stack that most directly determines whether your venue is a venue or a curiosity. The good news is that it's also the part where the heavy lifting is already done.