Crypto contract multiplier: convert order size

A crypto contract multiplier tells you how much underlying exposure or quote face value one contract represents. To calculate order size, convert the target into contracts, apply that instrument's quantity increment, then translate the rounded result into the unit accepted by its order endpoint. Base units, USD face value and contract count are different inputs; using the right number with the wrong unit can change the exposure by a large factor.

This is a quantity-conversion problem before it is a profit-and-loss problem. The linear versus inverse contract comparison explains settlement and collateral accounting; the worksheet below concentrates on what an order actually asks the venue to trade.

Separate exposure, contract count and submitted amount

Start with three entries: the intended exposure, the economic size of one contract, and the unit accepted by the request field. “Buy 100” is incomplete until the last entry is known. It might mean 100 BTC, 100 contracts or 100 USD of face value.

For a simple base-denominated contract, let m be the base units represented by one contract, n the contract count and P the reference price in quote units per base unit. Then:

• Base exposure = n × m.
• Estimated quote notional = n × m × P.
• Contracts for a base target Q = Q ÷ m.
• Contracts for a quote-notional target V = V ÷ (m × P).

For a fixed quote-face contract, let f be quote currency per contract. Face value is n × f; its base equivalent at the chosen price is (n × f) ÷ P. A target face value V therefore requires V ÷ f contracts before rounding. A base-equivalent target Q at price P requires (Q × P) ÷ f; that conversion changes with the valuation price.

These equations describe the two simple structures. A quanto contract or another specialized payoff needs its own specification. Also, “multiplier” here means the effective economic conversion; it is not permission to multiply every API field containing that word.

OKX documents derivatives order size sz in contracts, linear ctVal in base currency and inverse ctVal in USD. It exposes a separate ctMult field, but its documented notional formulas use sz × ctVal × markPx for linear instruments and sz × ctVal for inverse instruments. Follow the product formula. OKX instrument and order-size definitions.

Actual specifications can permit fractional contracts

A contract count does not automatically mean an integer. In the OKX BTC-USDT-SWAP public response reviewed on 26 October 2026, ctVal was 0.01 BTC, ctMult was 1, and both lotSz and minSz were 0.01 contracts. The settlement asset was USDT. These are a dated specification snapshot, not permanent trading limits. OKX BTC-USDT-SWAP instrument response.

Consequently, one permitted 0.01-contract increment represents 0.01 × 0.01 = 0.0001 BTC. Mistaking the contract increment for a BTC increment changes the conversion by a factor of 100. Forcing every contract count to a whole number would also discard valid sizes in this particular snapshot.

Use distinct names in a worksheet: baseTargetBTC, contractCount and submittedSizeContracts are clearer than three columns called “quantity.” Preserve the venue, product, environment, instrument identifier and specification observation time beside them. The symbol-mapping guide covers how to establish that instrument identity before applying a multiplier.

Worked example: convert a BTC target, then round

Assume a hypothetical target of 0.02735 BTC of exposure using the OKX contract specification above. Use an illustrative reference price of 60,000 USDT per BTC. This is neither a live quote nor a recommended position; the calculation excludes fees, margin requirements and execution costs.

The raw size is 0.02735 ÷ 0.01 = 2.735 contracts. It is not on a 0.01-contract grid. If the target is a maximum exposure, floor the positive size to that grid:

rounded contracts = floor(raw contracts ÷ step) × step

The proposed submitted quantity is 2.73 contracts. Rounding to the nearest increment without a direction policy could choose 2.74 and exceed the maximum. Downward rounding is a policy for this positive maximum-size example, not a universal rule for every hedge or closing instruction.

OKX defines lotSz as the size increment and requires size to meet minSz as well as the increment rule. Price ticks and other applicable limits still need checking. OKX lot-size and minimum-size rules.

If the rounded count is below the permitted minimum, no valid order fits that maximum under those specifications. The order-minimum feasibility worksheet explains when the right outcome is to stop and revise the plan, rather than silently increase its size.

Do the arithmetic with decimal values or scaled integers. The API decimal-precision guide explains why binary floating-point flooring can unexpectedly lose a step. A mathematically correct conversion is useful only if the serialized request preserves it.

An inverse API may want USD rather than contract count

Deribit's BTC-PERPETUAL has a documented 10 USD contract size, while its amount field uses USD. Its specification explicitly distinguishes an amount of 1,000 USD from the corresponding 100 contracts. It also says the instrument's lot_size field is reserved for future use; order sizing uses contract_size and min_trade_amount. Deribit inverse-perpetual contract-size guidance.

Deribit's instrument reference defines min_trade_amount as both the minimum and the order-amount increment, separately from contract_size. The BTC-PERPETUAL response checked on 26 October 2026 returned 10 for each, with lot_size equal to 1. That 1 is not a one-dollar trading step. Deribit size-field definitions, BTC-PERPETUAL instrument response.

Take a separate hypothetical maximum face value of 1,641 USD. This is a USD example, with no assumed conversion from the earlier USDT budget. Dividing by 10 USD per contract gives 164.1 contracts. With a 10 USD amount increment, flooring yields 164 contracts and a submitted amount of 1,640 USD, leaving 1 USD unused. At an illustrative BTC price of 60,000 USD, the base equivalent is approximately 0.02733333 BTC.

The calculation must end in the endpoint's requested unit. Sending 164 because the worksheet says “164 contracts” would send 164 USD, not 164 contracts, and would not fit the 10 USD contract increment. Some unit errors can still look valid: sending an amount of 100 USD when intending 100 contracts requests only 10 contracts, one tenth of the intended 1,000 USD face value.

The reverse check catches both cases: parse the proposed submitted amount back into contracts and face value. Compare that reconstructed exposure with the original target before considering an order ready.

Decide whether the target is base units or quote notional

A changing price can make a stale conversion wrong even when the multiplier has not changed. The rounded linear example retains 0.0273 BTC of exposure. At 65,000 USDT per BTC, that represents 1,774.50 USDT rather than 1,638 USDT.

If the original objective was a maximum of 0.02735 BTC, the base calculation still meets it. If the objective was a maximum of 1,641 USDT at the new reference price, recompute: 1,641 ÷ (0.01 × 65,000) = approximately 2.524615 contracts. Flooring to 0.01 contracts gives 2.52, representing 0.0252 BTC and 1,638 USDT at that price.

Name the constraint and its valuation price explicitly. An estimated notional based on a reference price is not a guaranteed market-order spend. A hard execution bound requires the appropriate venue order controls and applicable validation rules; it cannot be created by choosing a convenient last-trade price.

Reconcile fills in the same units

Suppose the illustrative 2.73-contract order fills 1.40 contracts and the remaining 1.33 contracts are canceled. The filled exposure is 0.0140 BTC; the canceled quantity represents 0.0133 BTC. Together they reconstruct the original 0.0273 BTC request.

A replacement plan should begin with the reconciled fill, not assume that the full requested size remains unfilled. Keep requested count, cumulative filled count, canceled remainder and resulting base exposure in separate fields. Otherwise, resubmitting 2.73 contracts can duplicate the portion already executed.

Keep the specification used for that order with the fill record. If a contract is replaced or its denomination changes, today's multiplier may not explain an old fill. A historical conversion needs the applicable historical contract terms, not a fresh lookup attached to an old event.

Validate the translated request before treating it as executable

A usable pretrade record should answer five questions:

1. What is the target, in which unit, and is it an exact target or a maximum?
2. Which verified instrument specification converts that target into a native amount?
3. What rounding policy was applied, and how much exposure changed?
4. Does the rounded request pass the relevant size, price, balance, margin and account checks?
5. Does converting the submitted amount back reproduce the intended exposure within the allowed difference?

Notional is not the cash required to open a position or a maximum loss. A correct multiplier does not determine when collateral becomes exhausted. The insurance-fund and bankruptcy-price guide explains the separate liquidation accounting boundary.

Changing products to obtain a finer order increment also changes the trade's requirements. A short through borrowed spot assets needs available borrow inventory; the margin-short borrow-availability guide covers that dependency. A derivative's contract count cannot be copied into a spot-margin order.

Before using any sizing worksheet, write one explicit identity: submitted amount, its native unit, reconstructed contracts, and reconstructed exposure. If those four entries do not agree with the target and current specification, resolve the conversion before submitting the request.