Resolution is the hard part of a prediction market
Order books get the attention, but what decides whether a prediction market is trusted is the part that settles the outcome. How resolution really breaks.
Most engineering write-ups about prediction markets are about matching. Order book or AMM, on-chain or off-chain, how to bootstrap liquidity in a thin market. Those are real problems, and they are also the ones with known answers — you can borrow a design from any exchange and adapt it.
Resolution has no equivalent playbook. It is the step where a market that has been trading on "will X happen by date D" turns into a payout, and it is the step where trust is won or destroyed. Everything before it is plumbing.
The question is never as crisp as it looks
A market reads "Will the Fed cut rates in September?" and everyone nods. Then September arrives with an intermeeting cut, or a cut announced in September but effective in October, or a 25bp cut when half the traders assumed the market meant 50bp.
The failure here is not the oracle. It is that the question was written in natural language for humans and settled by a mechanism that needs a boolean.
The most expensive bugs in a prediction market are written in the market description, not the contract. A rule that resolves ambiguously under a plausible real-world outcome will eventually meet that outcome.
Practical consequence: the market creation flow needs to be as engineered as the trading flow. Named resolution sources, an explicit "what if the source does not publish" branch, and a stated timezone are not paperwork — they are the spec the settlement code implements.
Three resolution models, three failure modes
Single trusted resolver. Fast, cheap, and the model most new platforms ship first. The failure mode is not usually fraud — it is unavailability. The resolver goes quiet, and every market waiting on them is frozen with capital locked inside.
Oracle with a dispute window. Someone proposes an outcome, a bond backs the proposal, and a window opens for challenges. This is the model most on-chain markets converge on. The failure mode is economic: if the bond is smaller than the payout an attacker stands to gain, disputing becomes profitable. Bond sizing is not a config value you pick once — it has to scale with open interest.
Committee or vote. Distributes the trust, adds latency, and introduces the problem that voters who hold positions are not neutral. Separating voting power from market exposure is harder than it sounds.
None of these is correct in the abstract. The right one depends on how much capital sits in a typical market and how much latency traders tolerate before they stop believing they will get paid.
What we build for on day one
The parts of resolution that are painful to retrofit:
- An explicit unresolved state with defined escape hatches. Markets that cannot settle need a path — refund, extend, or escalate — decided before it happens, not during an incident.
- Resolution data stored, not just applied. Which source, which value, which timestamp, which address submitted it. When a trader disputes a settlement six months later, "the contract says so" is not an answer.
- Bond parameters that read from open interest, so a market that grows past its original assumptions does not silently become attackable.
- A pause that stops trading without stopping withdrawals. Freezing everything during an incident converts a resolution problem into a solvency-panic problem.
The unglamorous conclusion
Liquidity determines whether a prediction market is usable. Resolution determines whether it is believed. A platform with thin books and impeccable settlement recovers; a platform with deep books and one contested settlement does not.
If you are scoping a prediction-market build, spend the first design week on resolution rules and the dispute path. The matching engine can be improved after launch. The reputation from a botched settlement cannot.
Read next
What to do in the two weeks before a smart-contract audit
Auditors bill for time, and most of it goes on things you could hand over upfront. How to prepare a codebase so the audit finds bugs, not context.
AI broke a post-quantum signature in 60 hours. The signature is not the problem
HAWK survived two years of expert review and did not survive a weekend with Anthropic's model. What that breaks is an assumption inside your architecture.
LLM costs do not scale the way your intuition says
A feature costing cents in a demo can cost thousands a month in production, and rarely because of the price per token. Where the money actually goes.