Same BTC Perp, Two Leverage Ceilings: 150x on One Venue, 100x on the Other — Both Straight From the API

Disclosure: This article was written with AI assistance under human editorial review. Data below was pulled live from public exchange endpoints and may change at any time.

#ad / Affiliate disclosure: This article currently contains no affiliate links. If that ever changes, affiliate links will be marked clearly here and at each link.

Not financial advice. This is an observation about publicly published contract specifications, not a recommendation to use leverage, trade perpetual futures, or choose one venue over another. Leverage magnifies losses as fast as gains, and liquidation can erase your margin in a single candle.

The question, kept simple

Bitcoin's most traded derivative in crypto-native circles is the BTC/USDT perpetual futures contract. Nearly every major venue lists one, and the underlying is identical: one Bitcoin, priced against Tether.

But the rulebooks are not identical. A previous piece in this series compared funding-rate mechanics; this one asks a single, concrete question:

What is the maximum leverage the exchange itself advertises for its BTC/USDT perpetual — as published in its own public API, today?

Two of the largest venues answer without requiring a login, a key, or a page full of JavaScript. We queried both, twice each, on 13 October 2026 between 02:07 and 02:11 UTC.

Venue A: the field is called maxLeverage, and it says 150

Bybit publishes contract specifications through a authentication-free GET endpoint:

GET https://api.bybit.com/v5/market/instruments-info?category=linear&symbol=BTCUSDT

The relevant fields from our capture (identical in both requests, at 02:08 and 02:10 UTC):

Field	Value
contractType	LinearPerpetual
status	Trading
settleCoin	USDT
leverageFilter.maxLeverage	150.00
leverageFilter.minLeverage	1
lotSizeFilter.minOrderQty	0.001 BTC
lotSizeFilter.minNotionalValue	5 USDT
upperFundingRate / lowerFundingRate	±0.00333
fundingInterval	480 minutes (8 hours)

So the headline number for the same contract: 150x.

Venue B: the field is called lever, and it says 100

OKX serves the same category of information through its own authentication-free endpoint:

GET https://www.okx.com/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP

Our capture (identical in both requests):

Field	Value
instType / ctType	SWAP / linear
state	live
lever	100
ctVal / ctValCcy	0.01 BTC per contract
minSz	0.01 contracts
uly	BTC-USDT
settleCcy	USDT

A companion endpoint, GET /api/v5/public/funding-rate?instId=BTC-USDT-SWAP, returned maxFundingRate = 0.00375 at the same moment — a useful cross-check that these are genuinely two independently maintained rulebooks sitting on top of the same underlying asset.

150 vs 100: what the gap actually means

The advertised ceiling differs by half again: 150x versus 100x, the same contract family, the same day, the same minute.

Three honest caveats before anyone treats this as a scoreboard:

1. The ceiling is an upper bound on a selector, not a promise. Both venues run tiered risk systems: as position size grows, the maximum leverage you can actually open drops in steps, and the maintenance-margin requirement that defines your distance to liquidation rises. The headline number typically applies only to the smallest position tier. (We have measured those staircases separately in an earlier piece; they are published on the very same public endpoints.)
2. The units are not the same. Bybit quotes order size directly in BTC (minOrderQty 0.001, a qtyStep of 0.001). OKX quotes in contracts: one BTC-USDT-SWAP contract (ctVal) is 0.01 BTC, and the minimum order (minSz) is 0.01 of a contract — one ten-thousandth of a coin. A naive script that reads "minimum size" from both APIs and compares the raw numbers is comparing coins to contracts.
3. A ceiling is not a risk comparison. We are not claiming either venue is safer, cheaper, or better. What we are claiming is narrow and checkable: the field exists, the field is public, and today the values read 150 and 100.

Why this belongs in the "fees are not the only fine print" series

Fee schedules get all the attention, yet the rulebook around a trade — maximum leverage, tick size, funding caps, order minimums, price collars — is a second layer of costs and constraints that differs from venue to venue far more than most traders expect. And crucially, most of it is now machine-readable: no login, no scraping of a JavaScript page, just a documented GET request whose answer is a number.

If you are comparing venues, the leverage field is one line in a table you can build yourself in ten minutes. The two endpoints above are the starting point.

Verify official sources

Do not take our word for any number in this piece. At any time you can re-run:

• https://api.bybit.com/v5/market/instruments-info?category=linear&symbol=BTCUSDT — the maxLeverage and minNotionalValue fields
• https://api.bybit.com/v5/market/tickers?category=linear&symbol=BTCUSDT — the fundingCap field (read 0.00333 at 02:07 UTC)
• https://www.okx.com/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP — the lever, ctVal and minSz fields
• https://www.okx.com/api/v5/public/funding-rate?instId=BTC-USDT-SWAP — the maxFundingRate field
• Field definitions: the Bybit market-instruments documentation at bybit-exchange.github.io/docs/v5/market/instrument and the OKX API v5 documentation at www.okx.com/docs-v5/en/ — both fetched live at those addresses, HTTP 200, at 02:10 UTC on 2026-10-13

All figures in this article are values returned by those endpoints at 02:07–02:11 UTC on 13 October 2026. Exchanges revise specifications without notice. Always confirm against the venue's own endpoints and pages before acting on any specification.

Once more, plainly: this post is informational only and is Not financial advice. Perpetual futures with high leverage can lose more than your initial margin. Trade only what you can afford to lose, and verify everything.

Written with AI assistance; all numbers were machine-read from the cited official endpoints and double-checked in two independent fetches.