# Implied probability

Also written market-implied probability, price as probability.

*https://predictionmarkets.tools/glossary/implied-probability · next to Prediction Market Data APIs*

**Definition:** The price of a binary contract that pays one dollar, read as the chance that it settles YES: 37 cents reads as 37 percent. It is a reading of a price, not a measured probability. Which price is read, the spread, the fee, the venue's tick grid and its rule text all move the number, so two screens can show different probabilities for what looks like one event.

Every venue in this catalogue sells a contract that pays a dollar if something happens and nothing
if it does not, and nearly every screen that shows one prints its price as a percentage. The
conversion is one division. What it hides is the reason the number on one screen rarely matches
the number on the next.

## How it works

**The arithmetic.** A contract that pays $1 and costs $0.37 breaks even, before costs, if it wins 37
times in 100. So the price divided by the payout is the probability at which buying is a fair price,
and that is what "implied" means: the probability the price implies, not one anybody measured.
Polymarket's documentation puts it in a table — $0.25 is a 25% chance, $0.50 a 50% chance. Kalshi
writes the same idea into its fee schedule, defining the expected earnings on a contract as the
maximum earnings times "the implied probability" of making them, which it sets equal to the price
divided by $1.

**Which price.** A contract with a bid and an ask has at least three candidate prices, and the
screen picks one. Polymarket's documentation says its displayed price is the midpoint of the bid
and the ask, and that when the spread is wider than 10 cents the last traded price is shown
instead. Its own worked example has a bid of 34 and an ask of 40: the screen says 37%, you pay 40
to buy and receive 34 to sell. Neither of the prices you can actually trade at is the one printed.

**Which unit.** The same quantity arrives in at least three scales. Kalshi's API returns prices as
fixed-point dollar strings with up to four decimal places, and its documentation warns that the
older integer-cent fields cannot represent sub-cent prices on markets whose tick grid goes below a
cent — some grids step by a tenth of a cent near the ends of the range. [Polyrama](https://predictionmarkets.tools/tools/polyrama) normalises
both of its venues to 0–1, [Adjacent](https://predictionmarkets.tools/tools/adjacent) to 0–100. A tool that reads `0.37` as 37
cents in one feed and `37` as 37 dollars in another is not making a rounding error; it is reporting
a contract at a hundred times its price.

**Odds are the same number upside down.** Decimal odds are the payout divided by the price, so a
37-cent contract is odds of about 2.70, and a "multiplier" display is the same thing. The
conversion is exact only when nothing is taken out. The [Limitless](https://predictionmarkets.tools/tools/limitless) card records
its Packs carrying a 10% vig already baked into the displayed multiplier, so the probability you
would back out of that multiplier is not the one the product is priced on.

## Why it matters here

**The fee moves the break-even, not the screen.** Paying 37 cents plus a fee means the contract
has to win more than 37 times in 100 to break even. On a schedule like Kalshi's, where the fee
scales with price times one minus price, that extra is largest in cents near 50 and largest as a
share of the stake on cheap contracts. The catalogue normalises fees to one unit for this reason —
see [effective fee at fifty cents](https://predictionmarkets.tools/glossary/effective-fee-at-fifty-cents) and
[what a trade actually costs](https://predictionmarkets.tools/guides/what-a-trade-actually-costs).

**Mutually exclusive outcomes do not sum to exactly 100%.** On a multi-outcome event the
percentages printed beside the outcomes add up to something near 100 and almost never to 100 —
spreads, thin books on long shots and the midpoint-or-last-trade rule all leave a gap. On
Polymarket the [neg-risk](https://predictionmarkets.tools/glossary/neg-risk) page shows how far apart they were on one day.
Normalising them to sum to one is a modelling choice, and a tool that does it silently is showing
you its model, not the market.

**Two venues are pricing two contracts.** A 61% on one venue and a 57% on another for "the same"
event are often not a disagreement about the world. The rule texts name different
[settlement sources](https://predictionmarkets.tools/glossary/settlement-source) and close times, the fees are charged on
different bases, the collateral differs, and one side may be a last trade from an hour ago. The
full breakdown is in
[why the same contract costs two different prices](https://predictionmarkets.tools/guides/why-the-same-contract-costs-two-prices).
Treat a cross-venue gap as a list of differences to account for before treating it as an
opportunity.

**It is a probability of settlement, not of the event.** The contract pays on what its rules say
and what its resolver decides. Where the wording, the source or the resolver could go another way,
the price includes that, and a reader using it as a forecast of the underlying event is reading in
something the price never promised. [Calibration](https://predictionmarkets.tools/glossary/calibration) is the measure of whether
those percentages have, over many contracts, come true as often as they said.

## Where you will meet this

- [Adjacent](https://predictionmarkets.tools/tools/adjacent.md)
- [Polyrama](https://predictionmarkets.tools/tools/polyrama.md)

## Sources

1. [Prices and Orderbook](https://docs.polymarket.com/concepts/prices-orderbook) — Polymarket, read 2026-10-04
2. [Fixed-Point Representation](https://docs.kalshi.com/getting_started/fixed_point_migration) — Kalshi, 2026-08-20
3. [Fee Schedule for July 2026 - 7.7.26 Update](https://kalshi.com/docs/kalshi-fee-schedule.pdf) — Kalshi, 2026-07-07

*Last updated 2026-10-04. A reference page, corrected in place — not a dated post.*