One OKX Contract Is Not One Coin: Sizes, Notional and Precision

The size field is a count

Every derivatives order on OKX carries a size field, and on futures and perpetual swaps that field is a number of contracts. The number is not a quantity of BTC, ETH or dollars. The conversion lives in the instrument record, which is public and needs no key.

For BTC-USDT-SWAP, read on 2026-10-30, the endpoint returned:

Read together, those rows answer the question “how much am I trading” in three different units, and mixing them up is where sizing errors come from.

Coins, notional and margin are three numbers

Take a position of 5 contracts on BTC-USDT-SWAP at a mark price of 68,000 USDT.

• Coins: 5 × 0.01 × 1 = 0.05 BTC.
• Notional: 0.05 × 68,000 = 3,400 USDT. OKX documents the same arithmetic directly — notional is size × contract value × mark price for linear contracts.
• Margin: notional divided by the leverage you selected, subject to the instrument’s maximum. At 10× that is 340 USDT of initial margin; at 100× it is 34 USDT.

The third number is the one people quote and the first two are the ones that decide outcomes. Liquidation distance scales with margin, but profit and loss scale with notional, and notional is fixed by the contract count, not by the leverage setting. Raising leverage on the same 5 contracts does not change what a one-percent move does to the position; it only changes how much of the account is set aside and how far price can move before the position is closed.

Inverse contracts run the arithmetic backwards

BTC-USD-SWAP is the same underlying with a different contract definition. Read on 2026-10-30 it returned ctVal 100 with ctValCcy USD, ctType inverse, lotSz 0.1 and settleCcy BTC.

So one contract is 100 USD of face value, and 10 contracts are 1,000 USD of face value regardless of the BTC price. The coin quantity is therefore a function of price: at 68,000 USDT per BTC, 1,000 USD of face is about 0.0147 BTC, and at 50,000 it is 0.02 BTC. The position’s coin size moves as price moves; its dollar size does not.

That inversion propagates into profit and loss. OKX documents the linear formula as (mark price − average price) × position × contract value, and the inverse formula as (1 ÷ average price − 1 ÷ mark price) × position × contract value. The division is not a formatting quirk — it is the mechanical consequence of a contract whose face is denominated in dollars and settled in coin.

The two rounding rules that reject orders

OKX publishes two independent increments, and an order must satisfy both.

tickSz is the price increment. On BTC-USDT-SWAP it was 0.1 USDT, which means a price of 68,000.05 is not representable. lotSz is the size increment, expressed in contracts: 0.01 contracts on BTC-USDT-SWAP, so sizes must land on hundredths of a contract. minSz sets the floor, and on this instrument it equals the lot step.

Two consequences follow that are easy to miss:

1. The size step is not a coin step. A 0.01-contract step on a 0.01 BTC contract is a 0.0001 BTC increment. A hedging script that rounds to 0.01 BTC is rounding 100 times coarser than the venue requires, and one that rounds to 0.01 BTC of notional is rounding the wrong unit entirely.
2. The minimum is a hard floor, not a warning. An order below minSz is rejected. If a risk budget — say 2 USDT of risk per trade — implies a position smaller than one contract’s notional, the strategy cannot be expressed on that instrument. The instrument’s price per contract is the granularity of the whole plan.

This is the same class of failure described in why an exchange rejects your order, applied to a venue that measures size in contracts. The rejection is free; the strategy that silently produces zero trades for a week is not.

From a risk budget to a contract count

The sizing loop, in the order that avoids most mistakes:

1. Pick the risk in quote currency. One percent of a 10,000 USDT account is 100 USDT.
2. Pick the stop distance in price. A stop 500 USDT away from entry.
3. Compute the notional that makes that stop worth 100 USDT. 100 ÷ 500 × 68,000 = 13,600 USDT of notional — but check the direction: notional × (stop distance ÷ price) = loss, so notional = loss ÷ (stop distance ÷ price) = 100 ÷ 0.00735 ≈ 13,600 USDT.
4. Convert to contracts. 13,600 ÷ (0.01 × 68,000) = 20 contracts exactly.
5. Apply the lot step. 20 is a multiple of 0.01, so it stands.

The fifth step is where a real account diverges from the model. If step 4 had produced 20.007, the correct action is to round down to 20.00 and accept slightly less risk, not to round to 20.01 and breach the budget. On a 100x-leverage instrument the difference between those choices is small per trade and compounding over a hundred trades.

The position size calculator does steps 1 to 3; the contract conversion is venue-specific and has to be done against the instrument record, because ctVal differs per symbol — 0.01 BTC on BTC-USDT-SWAP, 0.1 ETH on ETH-USDT-SWAP, 100 USD on BTC-USD-SWAP, all read on the same day.

What the instrument record changes without notice

The fields above are read from a live endpoint for a reason: they are operational settings, not constants. OKX’s documentation gives state values that include suspend, post_only, preopen and settling, any of which changes what an order will do even though the contract value has not moved. maxMktSz and posLmtAmt cap order and position size per instrument and can be revised.

A sizing model that hardcodes 0.01 is correct until the day it is not, and the failure mode is a rejected order or, worse, a position five times larger than intended if the venue ever increases the contract value. Reading the instrument record at startup, and re-reading it when a symbol enters a new state, costs one request and removes the entire class of error.

Two related mechanics complete the picture. Funding on these perpetuals is charged against the position’s notional, not the margin posted, which is why a 20-contract position pays the same funding as any other 13,600 USDT of exposure — the calculation is set out in funding rate, mark price and open interest. And liquidation is computed from maintenance margin against notional, so the same contract count liquidates at the same distance regardless of how much extra margin sits in the account, which portfolio margin risk explains for accounts that share collateral across positions.

The sanity check that catches most mistakes

Before sending an order, one multiplication catches the errors the filters will not.

Take the contract count, multiply by ctVal, and confirm the result is the exposure the strategy intended. On BTC-USDT-SWAP that is contracts × 0.01 BTC; on BTC-USD-SWAP it is contracts × 100 USD. If the answer is off by a factor of ten, the model has been written against the wrong contract type, and the venue will happily accept the order because the size passes minSz and lotSz.

The second check is against maxMktSz and the instrument’s state. A size that is legal in isolation can still be rejected because the market is in post_only or preopen, or because the order exceeds the per-instrument cap — and a state change is invisible in a stored constant while being obvious in a fresh read of the instrument record.

Risk note. Contract values, lot and minimum sizes, tick sizes, leverage caps and state values in this article were read from OKX’s public instrument endpoint and API documentation on 2026-10-30. They are venue settings and change; the conversion method does not. Nothing here is investment advice.