How Bitcoin Options Max Pain Is Worked Out From Open Interest, and How the Settlement Price Is Set

Bitcoin options max pain is a price on a given expiry date with one property: if settlement landed exactly there, all the calls and puts still open would pay their buyers the least money in total. Seen from the other side, it's also where option sellers pay out the least; the "pain" refers to the buyers. It's a number worked out from how open interest is spread across strikes, and on its own it carries no forecast of where the market is going.

Every expiry date has its own max pain, and it can move whenever positions change. What actually decides the payout is the settlement price, and both Binance and Deribit take a half-hour average: Binance uses the arithmetic mean of its spot index over the 0.5 hours before expiry, and Deribit uses a 30-minute time-weighted average of its index from 07:30 to 08:00 UTC. Because settlement is a half-hour average, pinning price to max pain means holding the index there for the whole window; section 4 runs the numbers.

1. How is max pain calculated? Add up what option buyers collect at expiry.

Call the expiry price S. If a strike K has C call contracts and P put contracts open, the buyers at that strike collect this much at expiry:

C × max(0, S − K) + P × max(0, K − S)

The max(0, …) part sets whichever side is out of the money to 0. Add this term up across every strike and you get "how much buyers collect in total if settlement is S." Repeat that for different values of S, and the S with the smallest total is max pain. Using each strike as a candidate price is enough: as S moves, the total changes along straight line segments, every kink sits on a strike, and so the lowest point is always found at one of the strikes.

Here's an example with four strikes, assuming each contract is worth 1 BTC:

Strike K	Call OI C (contracts)	Put OI P (contracts)
90,000	100	400
95,000	200	300
100,000	500	200
105,000	300	50

Illustrative data, not real positions. Both the contract counts and the strikes were made up to demonstrate the method and have nothing to do with any real expiry.

Plug each of the four strikes in as the settlement price and you get this (in USDT):

Assumed settlement S	Call buyers collect	Put buyers collect	Total
90,000	0	4,250,000	4,250,000
95,000	500,000	1,500,000	2,000,000
100,000	2,000,000	250,000	2,250,000
105,000	6,000,000	0	6,000,000

Break down the S = 95,000 row. On the call side only the 90,000 strike is in the money, at 5,000 per contract, and 100 contracts make 500,000. On the put side, the 100,000 strike pays 5,000 per contract on 200 contracts, or 1,000,000, and the 105,000 strike pays 10,000 on 50 contracts, or 500,000; together that's 1,500,000. The total of 2,000,000 is the smallest of the four rows, so max pain for this example table is 95,000.

Now look at the 100,000 row: a total of 2,250,000, only 250,000 above the low, or 12.5%. The bottom of the curve is flat, so a small change in positions can easily flip the answer. Raise the put open interest at 100,000 from 200 to 300 contracts. At S = 95,000, put buyers collect an extra 5,000 × 100 = 500,000, and the total becomes 2,500,000. At S = 100,000 those puts aren't in the money, so the total stays at 2,250,000. The low jumps to 100,000. A change of a hundred contracts moved max pain by 5,000.

The formula only counts intrinsic value at the moment of expiry. The premium buyers paid, the premium sellers received and any hedges either side holds are nowhere in it.

2. Where do you get Bitcoin options open interest for each strike?

What you need is a distribution table: for one expiry date, how much call and put open interest sits at each strike. Binance's public options market data API has one ready-made:

GET https://eapi.binance.com/eapi/v1/openInterest

Parameter	Required	Example value in the docs
underlyingAsset (underlying)	Yes	ETH/BTC
expiration (expiry date)	Yes	221225

The docs describe it as returning open interest for a given underlying on a given expiry date. It returns an array with one item per contract, each carrying four fields: symbol, sumOpenInterest, sumOpenInterestUsd and timestamp. The contract name in the response example is ETH-221119-1175-P. In the same docs, the exchangeInfo example maps BTC-220815-50000-C to strikePrice 50000 and side CALL, so a contract name breaks down as: underlying, six-digit expiry date, strike, then C (call) or P (put).

To turn the response into the table from section 1:

1. First call GET /eapi/v1/exchangeInfo and look in optionSymbols for the Bitcoin contracts currently listed. Each one carries expiryDate (a millisecond timestamp), strikePrice, side and unit. Pick the expiry date you want from there.
2. Call openInterest with underlyingAsset set to BTC and expiration set to that date in the same six-digit format as the example 221225, which is also how the date is written in the middle of the contract name.
3. Sort each row of the response into the call or put column by the C / P at the end of the symbol, place it on the right row by the strike in the middle, and fill in sumOpenInterest.
4. Run the formula from section 1 for every strike, total it, and take the smallest.

If your table ends up with fewer rows than exchangeInfo lists for that expiry, go back to step 1 and check that the date you entered matches an existing expiryDate. As for whether to multiply by the contract unit (the amount of the underlying one contract represents): if every contract on the same expiry has the same unit, each S total is scaled by the same factor, and which strike holds the low doesn't change. Keep the timestamp from the response, since it tells you which moment these positions belong to.

This table only covers Binance. Deribit's open interest has to come from its own public data, each venue gets its own calculation, and the two max pain figures don't have to match. Whether the two venues' positions can go into one table depends on whether they settle at the same price.

3. How is the options settlement price set? Binance and Deribit both average over half an hour.

The S in the formula above is, on an exchange, the settlement price. It isn't the trade price in the last second before expiry.

Binance's Help Center overview of options trading defines the settlement price as the arithmetic mean of the Binance spot index price over the 0.5 hours before expiry. Its worked example is ETH-211230-2000-C: the contract settles at 8:00:00 on 21-12-30, and its settlement price is the arithmetic mean of the ETH spot index from 7:30:00 to 8:00:00, written as 1/1800 × (Price_t1 + Price_t2 + … + Price_t1800), that is, 1,800 prices added up and divided by 1,800. The payoff formulas on the same page are MAX(settlement price − strike, 0) × unit × position size for a call buyer and MAX(strike − settlement price, 0) × unit × position size for a put buyer, the same structure used to build the totals above.

If you want a sense of where that average is heading before expiry, Binance's options 24-hour ticker endpoint (GET /eapi/v1/ticker) has an exercisePrice field. According to the docs, it returns the estimated settlement price during the hour before exercise and the index price the rest of the time.

Deribit's rules are on the Settlement page of its help center. For contracts expiring at 08:00 UTC, the delivery price is the 30-minute time-weighted average price (TWAP) of the relevant Deribit index between 07:30 and 08:00 UTC, with a snapshot taken every 4 seconds, which comes to 450 points over the 30 minutes. The options are European-style and cash-settled; anything in the money at expiry is exercised automatically and the profit is paid in cash, with no delivery of the coin itself. Depending on the contract type, they settle in BTC, ETH or USDC.

Item	Binance Options	Deribit
How the settlement price is set	Arithmetic mean of the Binance spot index price over the 0.5 hours before expiry	30-minute TWAP of the relevant Deribit index, 07:30–08:00 UTC, one snapshot every 4 seconds
Option style	European, settled daily, weekly, monthly or quarterly	European, cash-settled, in-the-money options exercised automatically
Settlement asset	In the API example, BTCUSDT has settleAsset USDT	BTC, ETH or USDC depending on contract type

The two venues use different indices and different averaging, so the same expiry date produces two separate settlement prices. That's why their open interest shouldn't simply be added together: the S each set of positions settles against is a different number to begin with.

4. Does price really get pinned to max pain on expiry day?

The picture behind this claim goes like this: option sellers lose the least at max pain, so they have a motive to push price there before settlement. That's a statement about sellers' motives. Whether a motive can turn into a settlement price depends on how that price is calculated.

On its Settlement page, Deribit explains that using a 30-minute TWAP together with several independent index constituent sources is meant precisely to reduce the risk of price manipulation at settlement. Binance's version, an arithmetic mean of 1,800 prices, likewise spreads the half hour out evenly. Suppose the index holds at 100,000 for the whole 30 minutes except for 3 minutes when it's pushed up 1% to 101,000. The average is (27 × 100,000 + 3 × 101,000) ÷ 30 = 100,100, only 0.1% higher.

Because settlement is a half-hour average, moving it toward a particular strike means holding the index near that level for the whole window. A sharp spike or dump in the last minute gets diluted by the other 29 minutes, and the capital and risk needed to keep pushing price are spread across the full stretch as well.

In the example table, a hundred extra put contracts at one strike moved max pain by 5,000. When someone says after the fact that "it got pinned to max pain again," first ask which venue's positions they used, and from what moment. Pull the data at a different moment and the target price being compared may no longer be the same one.

If you want to test it yourself, keep a log. For each expiry, in the hour before settlement, record the estimated settlement price from the ticker's exercisePrice, calculate max pain from openInterest at the same moment, and write both down together with the timestamp. Once you've collected enough expiries, check whether the gap between the two shows any pattern.

Whatever the log ends up showing, max pain shouldn't be read on its own. It squeezes an entire open interest table into a single price and throws away a lot of information in the process.

The same example table also gives you a put/call ratio (PCR). Total put open interest is 400 + 300 + 200 + 50 = 950 contracts, total call open interest is 100 + 200 + 500 + 300 = 1,100 contracts, so the open interest PCR is 950 ÷ 1,100 ≈ 0.86. Max pain tells you at which price buyers collect the least; PCR tells you whether puts or calls have more open interest. They answer different questions. PCR can be calculated from volume, from open interest or weighted by notional value; how to read it, and why a high PCR doesn't automatically mean bearish, is covered in Options put/call ratio: what crypto traders can and cannot infer.

In the example table, the heaviest call strike is 100,000 (500 contracts) and the heaviest put strike is 90,000 (400 contracts), with max pain at 95,000 in between. Report only the 95,000 and you can no longer see where those two piles of positions sit, so keep the per-strike open interest whenever you pull the data.

Pulling open interest for the same expiry yesterday and again today, and seeing which strikes are growing and which are shrinking, tells you more than how far the single max pain number moved. A big jump at one strike means new positions are being opened there. What rising or falling open interest corresponds to on the chart is explained in Open Interest Guide: The Leverage Still on the Table.

5. Max pain FAQ.