Skip to main content

Leverage Brackets & Position Limits

Overview​

Every USDⓈ-M perpetual market is provisioned with a small set of per-symbol risk parameters that, together, define how much leverage a user may pick and how large any single order or position may be. This page is the single source of truth for those limits — what they are, how they are exposed to API clients, and which of them act as hard admission gates on POST /fapi/v1/order.

Unified-Margin mode uses a different (notional-tiered) leverage schedule; see Unified Margin Overview. The rules below describe the default Isolated mode.

Per-Symbol Risk Parameters​

Each symbol carries the following configuration, managed centrally and hot-reloaded without redeploy:

ParameterTypical defaultSurfaced as
max_leverage100maxLeverage in exchangeInfo, used to clamp POST /fapi/v1/leverage
min_leverage1floor of POST /fapi/v1/leverage
min_order_size_usdsymbol-specifichard order gate (-1013 FILTER_FAILURE)
max_order_size_usdsymbol-specifichard order gate (-1013 FILTER_FAILURE)
max_position_size_usd10,000,000maxNotionalValue in Change Leverage and Position Risk responses
max_long_oi_usdsymbol-specificsymbol-wide cap on aggregate long open interest
max_short_oi_usdsymbol-specificsymbol-wide cap on aggregate short open interest

Limits can change over time — always read them from the live API rather than hard-coding values. Listing-day, post-listing stabilization windows, and volatility events are the most common reasons for ad-hoc tightening.

Leverage​

How leverage is selected​

A user's effective leverage on a given symbol is persisted rather than attached to each order:

  1. Call POST /fapi/v1/leverage to set the desired leverage. The request is validated against [min_leverage, max_leverage]; a violation returns -4028 Leverage {n} is not valid. Max: {max_leverage}.
  2. The accepted value is stored under (user, symbol).
  3. Subsequent POST /fapi/v1/order calls that do not carry an explicit leverage field read the persisted value and clamp it again to [1, max_leverage] at admission. If the symbol's max_leverage was lowered after the user set their preference, the lower of the two wins — the stored preference is not rewritten.
  4. If the user has never called POST /fapi/v1/leverage for a symbol, the order uses the symbol's current max_leverage as the default.

Updating leverage with open positions​

Lowering leverage with an open position does not modify the existing position's leverage or liquidation price — those were locked in at the time the position was opened (or, on add-on fills, at the time of the most recent add-on; see Order, Position & Leverage Flow). The change applies only to subsequent new orders.

Order-Size Limits​

Order quantity is first floored to the symbol's LOT_SIZE step. The resulting notional (quantity × ref_price, where ref_price is the limit price for LIMIT orders or the current mark price for MARKET orders) is then checked against [min_order_size_usd, max_order_size_usd]. Either side of the band returns -1013 FILTER_FAILURE with a specific message:

Order notional 12500.00 exceeds the maximum 10000 USD for ETHUSDT.
Order notional 4.50    is below the minimum 5 USD for ETHUSDT.

max_order_size_usd is the per-order ceiling. To open or grow a position beyond that ceiling, submit multiple orders.

Position-Size Limits​

max_position_size_usd is exposed as maxNotionalValue in the responses of:

Use this value to size up your strategy in advance — for example, to plan order ladders that respect the ceiling without bouncing on -1013.

Open-Interest Caps​

max_long_oi_usd and max_short_oi_usd cap the aggregate open interest on each side of a symbol across all users. They are evaluated for any order whose net effect would open or grow same-side exposure (pure-close orders and reduceOnly orders bypass this check). A breach returns:

{
  "error": "BTCUSDT OI cap exceeded on Long side: current $9800000, cap $10000000, requested delta $300000",
  "code": "OI_CAP_EXCEEDED"
}

When a side is already at cap, all new opens on that side are paused until existing positions reduce. Hedge orders against the opposite side are unaffected.

Leverage Brackets Endpoint​

For Binance-compatible tooling, the per-symbol leverage ladder can be fetched as a structured response:

HTTP Request​

GET /api/v1/open-interest/{symbol}/leverage-brackets

No authentication is required.

Response Example​

For a symbol whose max_leverage is 50:

[
  {
    "symbol": "BTCUSDT",
    "brackets": [
      { "bracket": 1, "initialLeverage": 50, "notionalCap": 50000,     "notionalFloor": 0,         "maintMarginRatio": "0.004", "cum": "0"       },
      { "bracket": 2, "initialLeverage": 50, "notionalCap": 250000,    "notionalFloor": 50000,     "maintMarginRatio": "0.005", "cum": "50"      },
      { "bracket": 3, "initialLeverage": 25, "notionalCap": 1000000,   "notionalFloor": 250000,    "maintMarginRatio": "0.01",  "cum": "1300"    },
      { "bracket": 4, "initialLeverage": 10, "notionalCap": 5000000,   "notionalFloor": 1000000,   "maintMarginRatio": "0.025", "cum": "16300"   },
      { "bracket": 5, "initialLeverage": 5,  "notionalCap": 10000000,  "notionalFloor": 5000000,   "maintMarginRatio": "0.05",  "cum": "141300"  },
      { "bracket": 6, "initialLeverage": 2,  "notionalCap": 50000000,  "notionalFloor": 10000000,  "maintMarginRatio": "0.1",   "cum": "641300"  },
      { "bracket": 7, "initialLeverage": 1,  "notionalCap": 100000000, "notionalFloor": 50000000,  "maintMarginRatio": "0.125", "cum": "1891300" }
    ]
  }
]

Field Semantics​

FieldMeaning
bracket1-indexed tier identifier
initialLeverageMaximum leverage permitted while position notional is in [notionalFloor, notionalCap). Capped from above by the symbol's max_leverage.
notionalFloor / notionalCapPosition notional band the tier covers, in USD
maintMarginRatioMaintenance margin rate that applies inside the tier
cumCumulative deduction (USD) used to keep the maintenance-margin ladder continuous: MM = notional × maintMarginRatio − cum

Isolated mode note: the brackets above are synthesized at request time from the symbol's max_leverage; tiers whose default leverage exceeds max_leverage are clamped down to it. In Isolated mode a single position thus sees one effective leverage cap (max_leverage) regardless of which tier its notional currently falls into; the brackets are surfaced primarily for compatibility with risk-display widgets and for parity with Unified-Margin mode, where the ladder is applied tier-by-tier.

Order Admission — Validation Order​

When you submit POST /fapi/v1/order, the limits above are evaluated in the following order. The first check that fails terminates the request:

  1. Symbol active & timestamp window — -1121 / signed-window errors
  2. LOT_SIZE — quantity floored to step
  3. Order notional band — min_order_size_usd ≤ quantity × ref_price ≤ max_order_size_usd (-1013)
  4. Leverage clamp — persisted leverage clamped to [1, max_leverage]
  5. reduceOnly constraints — opposite-side position must exist (-2022); quantity capped to position size
  6. Margin sufficiency — available_balance ≥ required_margin × (1 + buffer) (-2019)
  7. Open-interest cap — only when the order opens or grows same-side exposure (OI_CAP_EXCEEDED)
  8. Engine admission — engine-level checks (GTX cross, IOC/FOK semantics, etc.)

Any of these can be the failing edge — when investigating a rejected order, read the error code first; the mapping is one-to-one with the rule above.

See Also​