An amount, a count and a multiplier carry different units
A contract count answers how many contract units a quantity represents. A multiplier answers how much base quantity or quote face value each contract unit represents. A sizing step answers which increments a particular rule permits. Those are three different pieces of information, even when two numeric values happen to look alike.
The original converter remains available first: give it the payout type, input denomination, amount, multiplier and explicit base/quote labels. Its result is a dimensional conversion. The added optional floor shows how much denomination would remain unrepresented under your supplied contract-count step. It does not turn that mathematical floor into an accepted order.
Retain the original 100-contract example
The hypothetical linear example uses 0.001 BTC per contract. One hundred contracts represent 100 times 0.001, or 0.1 BTC. Entering 0.1 as base quantity divides by 0.001 and gives the same 100 contracts. No price is required because this is a base-unit conversion, not a calculation of quote notional.
Linear input therefore accepts contracts or base only. A USD quote amount cannot be divided by a BTC-per-contract multiplier without another priced conversion, so this form rejects it. It also rejects base input for the inverse branch. These original boundaries are retained rather than allowing a plausible-looking number with the wrong dimension.
For the inverse branch, quote face value is the denomination
An inverse input can be a contract count or a total quote face amount. If a hypothetical specification says 10 USD face per contract, 1005 USD face converts exactly to 100.5 contracts. That is a statement about denomination; it is not a settlement-coin amount, margin requirement or profit calculation.
Deribit documents BTC inverse-futures contract size in USD while settlement is in BTC, and its order amount also uses USD. Its base_currency field does not make contract_size a BTC amount. Use the exact product and method documentation when translating an export. Do not transfer the same field interpretation to options, linear products or another provider.
Sources: Deribit — Inverse Futures: denomination and contract size.
Do not substitute contract size for the order increment
The optional step field here is explicitly measured in contracts. Suppose a source gives an increment of 20 USD face and your multiplier is 10 USD per contract. The corresponding contract-count step is 20 divided by 10, or 2 contracts. Entering 20 as though it were already a contract step would change the result by a factor of ten.
Deribit's documented contract_size converts between amount and count; min_trade_amount supplies the order-amount minimum and increment in its own specified unit. The two fields are distinct. The API reference describes lot_size as a unit for fee-lot counting, while the support article still describes it as reserved. Those descriptions differ; neither makes lot_size the order-amount increment. This page does not fetch, populate or validate any live rule.
Sources: Deribit public/get_instrument — contract_size and min_trade_amount, Deribit — Inverse Futures: denomination and contract size.
Measure what an optional floor leaves out
The worksheet computes floor(C/S) times S from exact contract count C and supplied contract step S. It then multiplies the floored count by the same denomination multiplier. The remainder is the original converted denomination minus that represented amount. All these operations use exact fractions before any display rounding.
For the hypothetical 1005 USD face, 10 USD multiplier and 1-contract step, 100.5 contracts floor to 100; represented face is 1000 USD and the remainder is 5 USD. With a supplied 2-contract step, this example also floors to 100. With a 4-contract step, it still floors to 100, but other amounts may differ. These are assumptions illustrating the method, not a recommended order size or a current venue rule.
A missing step is not a one-contract rule
Leave the optional step blank and exact conversion remains available. Floored count, represented amount after floor and remainder remain unknown because the rule needed to compute them was not supplied. A fraction such as one third of a contract remains an exact rational output; it is not silently replaced by 0 or rounded up to 1.
A zero amount is different: when a valid step is supplied and the time check does not reject it, zero converts and floors to zero with zero remainder. A minimum order requirement is a different test and is not performed. Negative positions are outside this non-negative quantity converter; keep the trade side in its own record.
Check that a future specification is not used for an earlier record
The added record keeps two independent instants: when the calculation belongs in your journal and when the supplied specification becomes effective. If both are present, the audit compares the instants. An effective time later than the record time withholds the optional floor, while retaining the exact conversion as a calculation under the entered multiplier assumption.
If either timestamp is absent, the timing status stays unknown. A floor can still be displayed as arithmetic from supplied assumptions, but that does not establish applicability. An effective time in the past also does not prove that no newer revision exists. Retain the source version, instrument identifier and original specification with the exported calculation.
Keep UTC instants when the Singapore date changes
Singapore standard time is UTC+8. In the loaded hypothetical record, the specification effective instant of 2026-10-20T16:00:00Z is 21 October at 00:00 in Singapore. The calculation at 16:05 UTC is 00:05 on that same local date, so the expected Singapore date 2026-10-21 matches.
Writing the UTC calendar date 20 October into the Singapore journal-date field produces a mismatch. Moving the effective instant to 16:10 UTC makes it five minutes later than the calculation and withholds a supplied optional floor. These are concrete record checks, not claims about Singapore exchange access, contract availability or legal reporting deadlines.
Sources: Singapore BCA — Site Management Data Standards v1.1, page 65.
Save units and the unrounded basis with the result
Repeating fractions can otherwise conceal a rounding boundary. For example, 1 USD divided by a 3 USD-per-contract multiplier is exactly one third of a contract, not a finite twelve-place decimal. The optional step operation uses that exact fraction. Display and CSV decimal fields are rounded half-up to twelve places and accompanied by exact rational and precision fields.
The original contract-quantity-converter.csv filename and measure,value,unit layout are retained. Original Contracts and Base quantity or Quote face value measures remain, followed by the step audit and timestamps. The copy button has a visible manual-copy fallback; download uses the same current result. Formula-like text is escaped for spreadsheet safety. An input edit invalidates both calculation and export.
Finish the unit check before following the optional offer
The useful output is a traceable connection between amount, multiplier, count, optional step and remainder. An exact conversion can still be unsuitable for an actual order because price ticks, minimum amounts, state, expiry, available margin and other controls are outside this worksheet.
The full tool and explanation are usable without a sign-up. The optional link leads to this publisher's existing Telegram offer for crypto signals, setups and market updates. The offer does not certify the supplied specification or turn a rounded mathematical count into an accepted or profitable trade.
Worked examples
Example 1
- payout type
- linear
- input unit
- contracts
- amount
- 100
- multiplier
- 0.001
- base asset
- BTC
- quote asset
- USD
- contract step
- recorded at
- 2026-10-20T16:05:00Z
- spec effective at
- 2026-10-20T16:00:00Z
- journal date
- 2026-10-21
- contracts
- 100
- denominated amount
- 0.1
- rounded contracts
- unknown
- step status
- not_supplied
- journal date matches
- True
The original linear conversion remains complete; an unspecified step remains unknown.
Example 2
- payout type
- inverse
- input unit
- quote
- amount
- 1005
- multiplier
- 10
- base asset
- BTC
- quote asset
- USD
- contract step
- 1
- contracts
- 100.5
- rounded contracts
- 100
- rounded denominated amount
- 1000
- denomination remainder
- 5
- spec time status
- unknown
A hypothetical supplied step produces a floor, not an order-acceptance claim.
Example 3
- change
- Use the loaded record with contract_step=1 and spec_effective_at=2026-10-20T16:10:00Z
- spec time status
- not_yet_effective
- rounded contracts
- unknown
- contracts
- 100
Future specification timing withholds the floor but preserves conversion under the supplied assumption.
Questions before you use the result
Is contract size the same as the minimum trade increment?
Do not assume that. Read the exact product and method. This converter requires a multiplier and an optional step with explicit units.
Can I use quote amount in the linear branch?
No. That would require a price-based conversion outside this base-per-contract worksheet. Linear accepts contracts or base; inverse accepts contracts or quote face.
Does a fractional result mean the exchange accepts it?
No. The exact conversion can be fractional while venue sizing, minimum amounts and other checks remain unverified.
Why can the timing status be unknown while a floor is shown?
The floor is arithmetic from your supplied step. Without both timestamps, the worksheet does not establish whether that specification applied to the record.
Primary sources and scope
- Deribit — Inverse Futures: denomination and contract sizeChecked 2026-10-20. The documented BTC inverse future has USD contract size and BTC settlement. Order amount is USD face denomination, distinct from the resulting count of contracts. This is a checked documentation example, not a live instrument lookup.
- Deribit public/get_instrument — contract_size and min_trade_amountChecked 2026-10-20. Documentation distinguishes amount-to-contract conversion from quantity increment/minimum and their units by instrument type. It defines lot_size for fee-lot counting, differing from the support article; the worksheet uses neither interpretation as an order step. No instrument or account API was called.
- Singapore BCA — Site Management Data Standards v1.1, page 65Checked 2026-10-20. Page 65 identifies +08:00 as Singapore Standard Time (UTC+8). Used only for timestamp notation and date arithmetic; no construction, trading, legal or tax requirements are inferred.
Prepared from the sources listed above. Examples and calculations explain a method; they do not predict prices or certify an investment. Geographic time references do not establish where a trading service is available. Dated schedules can change: consult the named publisher before relying on a future event.