Prediction markets, briefly

This page defines the vocabulary the rest of the documentation uses. If the terms are already familiar, go to the Quickstart.

The contract

A prediction market is a market in contracts that settle on a real-world outcome. A contract pays out a fixed amount if the outcome happens and nothing if it does not.

Because the payout is fixed, the price is the interesting part. A contract that pays $1 if an event occurs trades between $0 and $1, and its price is commonly read as the market’s implied probability — 62¢ implies roughly a 62% chance. That reading is a useful shorthand rather than a precise claim: the price also carries the cost of tying up capital until settlement, the fees involved, and whatever risk appetite the participants have.

Most contracts are binary: the outcome either happened or it did not. Where a question has several possible answers, venues generally express it as a set of contracts, one per answer, rather than a single multi-way instrument.

Market, event, outcome

These three words appear constantly in this API and are not interchangeable.

• An outcome is the thing you actually hold a position in — one side of one question. “Yes” and “No” are two outcomes.
• A market is the question, holding its outcomes together. “Will the Fed cut rates in March?” is a market with two outcomes.
• An event groups related markets. A single election has many markets — one per candidate, or per state, or per margin — and the event is what ties them together.

Order books and price history key on the outcome, not the market, because a market has one book per side. Selecting an outcome before asking for depth or candles is the most common early integration step. See Events & series for how the grouping behaves across venues.

Resolution

Resolution is the point at which a market’s answer becomes final and contracts pay out. It is the least standardised part of prediction markets.

Venues differ on who decides, on what evidence, and how disputes are handled — some resolve from a named official source, some from an oracle, some from a committee. Two venues can carry what looks like the same question and settle it differently, because their resolution criteria differ in ways the title does not reveal.

This is why a price difference between two venues is not automatically a mispricing: if the two contracts can settle differently, they are not the same contract, and the gap may be entirely rational. Predictefy treats resolution-equivalence as something to be checked, not assumed — see Cross-venue data.

Why venues disagree

Prices for the same real-world question routinely differ across venues:

• Different participants. A venue’s users are not a random sample, and their collective view is not either.
• Different liquidity. A thin book moves further on the same order, so its price can drift from a deeper venue’s without anyone being wrong.
• Different costs. Fees, gas, and the capital cost of holding to settlement are not identical across venues, and they are priced in.
• Different resolution criteria. As above — sometimes the questions only look alike.

Predictefy reports these gaps as indicative price discrepancies: observed differences, not opportunities. Calling a gap arbitrage requires proving it survives live asks on both legs, open market status, real depth at the size you want, the actual fee model, and a resolution-equivalence check. That is a separate and much stronger claim, and only fetchArbitrage makes it.

Order books and liquidity

Most venues here run an order book: resting bids and asks, and a trade when they meet. The best bid and best ask bracket the current price, and the gap between them is the spread.

Some venues do not run a book at all — they use an automated market maker or a pari-mutuel pool, where price is a function of what has been staked rather than of resting orders. The API still returns a book-shaped response for those venues so that one integration works everywhere, but it labels the book synthetic. A synthetic book is a faithful representation of price; it is not executable depth, and should never be treated as orders you could fill against. Venue coverage records which venues have a real book.

What this means for an integration

Three rules follow, and the rest of the documentation assumes them:

1. Check capability before assuming support. Venues genuinely differ. A venue with no public trades tape answers NOT_SUPPORTED — an honest answer about the world, not an error to route around.
2. Read the honesty fields. Every record carries asOf, provenance, and capabilities. They tell you when the data was true, where it came from, and what the venue actually supports.
3. Do not equate similar-looking markets. Matching across venues is a judgement, and Predictefy exposes it as one — with a similarity score, not a promise.

Next: Quickstart for your first request, or Venue coverage for what each venue supports.