> ## Documentation index > Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt > Use it to discover every available page before exploring further. # Prediction markets, briefly > The domain vocabulary the rest of these docs assumes — contracts, outcomes, resolution, and why venues disagree. This page defines the vocabulary the rest of the documentation uses. If the terms are already familiar, go to the [Quickstart](/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](/guides/cross-venue/) 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](/guides/cross-venue/). ## 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`](/guides/cross-venue/) 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](/reference/venues/) 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](/quickstart/) for your first request, or [Venue coverage](/reference/venues/) for what each venue supports.