DEV Community

Cover image for Black-Scholes for Polymarket: Modeling Binary Market Probabilities
Bo$onaX
Bo$onaX

Posted on

Black-Scholes for Polymarket: Modeling Binary Market Probabilities

Learn how to adapt Black-Scholes binary-option math to Polymarket, estimate fair probabilities for BTC markets, and compare model probability with executable CLOB prices.

A Polymarket share already looks like a derivative: it trades between $0 and $1 and ultimately resolves to a binary payoff. That makes an obvious quantitative question:

Can Black-Scholes turn the current BTC price, strike, volatility, and time remaining into a fair Polymarket probability?

Yes—with an important qualification.

Black-Scholes is not a native Polymarket pricing model. It is better treated as a probability engine that generates an independent estimate of the chance that a specified terminal condition occurs. The trading decision then becomes:

model probability vs. executable market price.

By Bo$onaX

Polymarket trading bots • Quantitative trading • Rust • Web3 infrastructure

GitHub: https://github.com/n9xdev/poly-alpha-lab

Telegram: https://t.me/bosonax

YouTube: https://youtube.com/@bosonax

X: https://x.com/xxniiinxx

Polymarket: https://polymarket.com/@bosona

The useful connection: a Polymarket share resembles a digital option

Polymarket documents that outcome-token prices range from $0 to $1 and represent the market's implied probability. Its CLOB then determines actual executable bid and ask prices through supply and demand. :chatgpt-content-reference{index="5"}

A cash-or-nothing European call has an analogous payoff:

Payoff =
\begin{cases}
1 & S_T \ge K\\
0 & S_T < K
\end{cases}
Enter fullscreen mode Exit fullscreen mode

Under Black-Scholes assumptions, its theoretical value is:

V=e^{-rT}N(d_2)
Enter fullscreen mode Exit fullscreen mode

where

d_2 =
\frac{\ln(S/K)+(r-\frac12\sigma^2)T}
{\sigma\sqrt{T}}
Enter fullscreen mode Exit fullscreen mode

For a short-dated prediction market, the discount factor is usually negligible for practical probability estimation, giving:

P_{BS}\approx N(d_2)
Enter fullscreen mode Exit fullscreen mode

That is the interesting quantity: a model-implied terminal probability, not necessarily a tradable fair price.

The classical Black-Scholes framework was introduced by Fischer Black and Myron Scholes in their 1973 Journal of Political Economy paper. :chatgpt-content-reference{index="6"}

Example: BTC above a strike at expiry

Imagine a hypothetical Polymarket BTC market asking whether BTC finishes above $110,000 at a defined expiration.

Suppose:

  • BTC spot (S = \$108,000)
  • Strike (K = \$110,000)
  • Annualized volatility (\sigma = 60\%)
  • Time remaining (T = 2/365)
  • (r \approx 0)

Then the model produces a probability from (N(d_2)).

The trading bot does not simply buy whenever that probability exceeds 50%.

Instead, compare it with the executable order book.

If:

P_{model}=0.58
Enter fullscreen mode Exit fullscreen mode

and the best ask is:

P_{ask}=0.49
Enter fullscreen mode Exit fullscreen mode

the raw model edge is approximately:

0.58-0.49=0.09
Enter fullscreen mode Exit fullscreen mode

But 9 percentage points is not automatically 9% profit. Spread, fees, slippage, fill probability, latency and model error still matter.

Polymarket explicitly distinguishes displayed midpoint prices from executable bid/ask prices, so a bot should compare its model against the price it can actually trade, not merely the UI midpoint. :chatgpt-content-reference{index="7"}

Where Black-Scholes breaks

This is where a serious Polymarket implementation differs from an academic options calculator.

Black-Scholes assumes a continuous stochastic process with constant volatility and a conventional European exercise structure. Prediction markets can violate those assumptions badly.

A BTC market might depend on:

  • a specific price source;
  • a specific observation time;
  • a TWAP rather than instantaneous spot;
  • an unusual resolution rule;
  • discontinuous crypto price jumps;
  • rapidly changing volatility;
  • thin liquidity near expiry.

Polymarket's current documentation is particularly important for BTC Up/Down markets: these can use Chainlink TWAP observations, with the starting TWAP establishing the price-to-beat and the ending TWAP determining the final comparison. :chatgpt-content-reference{index="8"}

That means feeding Binance spot directly into Black-Scholes can produce a beautifully calculated probability for the wrong random variable.

The first engineering task is therefore not the formula.

It is defining exactly what (S_T) means.

Turning it into a Polymarket trading signal

A practical bot can separate the system into four layers:

Market Definition
      ↓
Underlying / TWAP Feed
      ↓
Probability Model
      ↓
CLOB Execution
Enter fullscreen mode Exit fullscreen mode

The market-definition layer supplies strike, expiry, direction and resolution rules.

The pricing layer estimates:

P_{model}=N(d_2)
Enter fullscreen mode Exit fullscreen mode

The execution layer reads actual order-book depth and calculates:

Edge=P_{model}-P_{ask}
Enter fullscreen mode Exit fullscreen mode

for a YES purchase, or the corresponding expression for NO.

Only after transaction costs and risk constraints should the strategy decide whether an order is justified.

Polymarket's current market-data documentation exposes order-book levels, timestamps, tick size, minimum order size and last-trade information—exactly the inputs a production implementation should preserve rather than reducing the market to one displayed price. :chatgpt-content-reference{index="9"}

A better use of Black-Scholes

The strongest application is therefore not:

“Black-Scholes tells me the correct Polymarket price.”

It is:

“Black-Scholes gives my bot an independent probability estimate that I can challenge against the market.”

That distinction matters.

If Polymarket trades YES at 52% while your model estimates 61%, you have a hypothesis worth investigating. You do not yet have alpha.

A production system should test whether the discrepancy survives:

  • bid/ask costs;
  • liquidity constraints;
  • volatility-estimation error;
  • stale underlying data;
  • resolution methodology;
  • execution latency;
  • adverse selection;
  • calibration error.

For repeated markets, probability calibration may ultimately be more valuable than the theoretical elegance of the formula.

Failure mode: confusing probability with price

A common implementation mistake is treating midpoint == fair_value.

It isn't.

The midpoint is simply a market-data observation. Polymarket states that displayed price is normally derived from the bid/ask midpoint, while execution occurs against the actual bid or ask. :chatgpt-content-reference{index="10"}

For a trading bot, maintain at least three values:

model_probability
best_bid
best_ask
Enter fullscreen mode Exit fullscreen mode

Then measure edge against the side you can actually execute.

That small distinction can completely change a backtest.

The more interesting research direction

Once the basic model works, Black-Scholes becomes a baseline rather than the final strategy.

A stronger probability engine could replace constant volatility with a realized-volatility estimator, incorporate TWAP-specific variance, condition volatility on market regime, or combine the analytical probability with a market-implied probability.

The useful output is not a prettier equation.

It is a continuously updated estimate of:

P(\text{resolution outcome}\mid\text{current information})
Enter fullscreen mode Exit fullscreen mode

compared against what the CLOB is charging.

That is where Black-Scholes Polymarket becomes genuinely interesting: not as a direct copy of traditional options pricing, but as a disciplined mathematical baseline for prediction-market probability estimation.

Risk disclaimer: This is an educational quantitative framework, not financial advice. A model probability is an estimate, not a guaranteed outcome, and live trading introduces execution, liquidity, model and resolution risks.

Top comments (0)