TLDR: A perpetual venue can refuse an order priced too far from its own reference price, and on Binance, Bybit and OKX that limit is published on a public unauthenticated endpoint you can read without an account. What almost nobody checks is that those three publish it in three different shapes: Binance ships a multiplier pair inside exchangeInfo, Bybit ships a ratio pair inside instruments-info, and OKX ships two absolute prices from a dedicated price-limit endpoint. Measured on 2026-08-11, all 858 USD-M futures symbols listed in Binance's own exchangeInfo response carried a band, and only 34 of the 697 genuine crypto perpetuals carried BTC's, so the band is a property of the symbol rather than of the venue. Read the band as a per-symbol parameter you look up, never as a venue-level constant you remember. This is education only, not a buy or sell call.
A price band is the least discussed risk control in crypto derivatives, which is odd, because it is the one that decides whether your order gets to exist. Liquidation engines, funding and margin tiers get written about constantly. The corridor outside which an order stops behaving normally is treated as plumbing. Then a market gaps, an order that looked perfectly sensible does not come back the way it went in, and the trader concludes the venue is broken. It is not broken. It published the corridor, in advance, in a machine-readable field, and the reason nobody read it is that no two venues publish it the same way, or do the same thing to you when you cross it.
What is a price band on a crypto perpetual?
A price band is a cap on how far ACROSS its own reference price a venue will let you price an order: how high a buy may go, how low a sell may go. It is worth being precise that it is not a box every order must sit inside, because you may rest a bid far below the reference all day and nothing stops you. It binds the aggressive side. It exists to stop a fat finger or a thin book from printing a trade far away from where the asset is actually valued, because such a print can trigger liquidations and mark-price moves that no real supply or demand justifies. Notice the deliberately loose wording: what the venue DOES to the offending order is not standardised at all, and that turns out to be the more useful thing to know. The band is also not a circuit breaker, and the two get conflated constantly. A circuit breaker halts a whole market for everyone and is a rare event; a price band is always on and acts on one order at a time, with the limit travelling along with the reference price. The distinction that actually holds here is narrower than the usual one, and it is worth stating exactly: none of these venues publishes a volatility-triggered halt RULE, the kind that stops the tape automatically once price has moved a set amount. Their halts are discretionary and operational, for maintenance, delisting or a technical fault. Binance ships literal TRADING_HALT and TRADING_CANCEL_ONLY contract states and OKX ships a suspend instrument state, so the machinery to stop a market plainly exists; what does not exist is a published rule that fires it on price alone. The continuous, rule-based control is the band. So "crypto has no automatic circuit breakers" and "crypto venues can suspend a contract, and routinely bound order prices" are both true at once.
Where does each venue publish its band?
All three of the venues below expose the parameter without an API key, so any claim about it is checkable in one request. The differences are in what the response actually hands you.
| Venue | Public endpoint | Shape of the published number | What you must supply to get a price |
|---|---|---|---|
| Binance USD-M | /fapi/v1/exchangeInfo, PERCENT_PRICE filter |
A multiplier pair, multiplierUp and multiplierDown, plus multiplierDecimal |
The reference price, which the venue supplies separately |
| Bybit linear | /v5/market/instruments-info, riskParameters |
A ratio pair, priceLimitRatioX and priceLimitRatioY |
Both ratios at once, two reference prices, and a live order-book premium term, assembled by a formula the venue publishes separately |
| OKX swaps | /api/v5/public/price-limit |
Two absolute prices, buyLmt and sellLmt, with a timestamp |
Nothing. The venue has already done the arithmetic |
Binance spells the arithmetic out in its own API reference, which is worth quoting because it settles what the coefficient attaches to: "The PERCENT_PRICE filter defines valid range for a price based on the mark price", with the rule stated as BUY: price <= markPrice * multiplierUp and SELL: price >= markPrice * multiplierDown. Two things follow that people usually miss. The reference is the MARK price, not the last trade you are looking at, so the corridor can move while the tape does not. And the rule is asymmetric by side: the up multiplier bounds your buys and the down multiplier bounds your sells, which is why the two are published as a pair rather than as one width. A third detail is easy to miss: Binance also publishes a separate market-order price cap in its trading-parameters pages that is not carried in exchangeInfo at all, so the filter you can read programmatically is not the whole of what governs your orders on that venue.
Bybit's number is the one that looks simplest and is not. Its published futures trading rules give the ceiling as Min ( Mark Price x (1 + Y%), Max (Index Price, Mark Price x (1 + X%) + a x Max (0, Premium Avg) ) ), where the premium average is a rolling 30-second average of the gap between the order book's mid price and the mark price. So X and Y are not two edges of one band, and you do not pick between them. Bybit defines X as a soft boundary configured per trading pair and Y as the hard outer boundary, and both appear in the same expression, which also reads the index price and that decaying premium, with a weighting factor the venue reserves the right to adjust. Two further details matter for anyone automating this: the API reference scopes riskParameters to the LIMIT order price specifically, and it notes that the formula changed in May 2026. Anyone reading priceLimitRatioX 0.01 as "a 1% band" has skipped all of that.
OKX, for its part, tells you plainly that you are not being given the whole rule: "OKX dynamically calculates the highest and lowest price limits for each instrument in real time, based on more than a dozen parameters such as trading volume, open interest, and the percentage of index deviation. To preserve its risk control effect, the full set of rules is not completely disclosed." That is an honest and, for our purposes, decisive sentence. It is also why OKX hands you the finished prices: the arithmetic is not something you could reproduce.
That last column is the whole point. OKX hands you a number you can compare to your order price immediately. Binance and Bybit hand you coefficients, and a coefficient is not a price until it is combined with a reference the venue defines elsewhere. On Binance that is one multiplication against the mark price. On Bybit, as the formula above shows, it is not one multiplication at all: it takes both ratios, two different reference prices and a live order-book term. Three venues, three levels of assembly required. Line those three up in one column labelled "price band" and the column has quietly invented a common unit that none of the three publishes.
Why the published numbers do not compare across venues
Because they are not the same quantity, and because they are not even constant within a venue. Measured on 2026-08-11 against Binance's own exchangeInfo response, 858 of 858 USD-M futures symbols listed in that response carried a PERCENT_PRICE filter, so coverage was total. The values were not, and the split is instructive once you separate the asset classes. Restricting to the 697 genuine crypto perpetuals, which is what this piece is about, 523 carried multiplierUp 1.1500, an upside cap of 15%; 113 carried 1.1000, or 10%; and only 34 carried the 1.0500, or 5%, that BTCUSDT and ETHUSDT sat at that day. The modal crypto perpetual band was three times wider than Bitcoin's, so a reader who generalised "the Binance band is 5%" from a Bitcoin example would have been wrong about 663 of the 697 crypto perpetuals. The tightest bucket on the whole venue, 155 symbols at 1.0300 or 3%, contains no crypto perpetual at all: every one of those 155 is a TradFi perpetual on an equity, a metal or an energy contract. That is an asset-class boundary, not a venue changing its mind about risk.
The same per-symbol logic showed up on Bybit in the same hour. BTCUSDT returned priceLimitRatioX 0.01 and priceLimitRatioY 0.02, while ETHUSDT returned 0.02 and 0.04, exactly double, on a venue where both are flagship linear contracts. None of these figures are quoted here as durable facts about either venue, and any of them may have been revised since the timestamp above. They are quoted as dated evidence for a structural claim that does survive a revision: the band is a per-symbol parameter under venue control, so the honest way to hold it is as a lookup, not as a remembered number.
What happens to an order that breaches the band?
Something different on each venue, and this is the part that is genuinely worth carrying around. The same order, priced the same distance outside the same kind of corridor, meets three different fates depending on where you sent it, and each venue documents its own in its own words.
| Venue | Documented consequence | The venue's own wording |
|---|---|---|
| Binance USD-M | The order expires | "a limit order will expire if the difference between the limit order price and the mark price exceeds the Limit Order Price Cap/Floor Ratio" |
| OKX | The order is rejected | "When the order price is higher than the highest price limit, the order is rejected" |
| Bybit | The order price is rewritten | "the system will automatically adjust the order price to the highest bid price allowed" |
Expired, rejected and silently repriced are three materially different outcomes for the same mistake. The first two leave you with no order and tell you so. The third can leave you with a live order at a price you did not choose, and Bybit's own worked example makes it conditional on a setting, ending "if the Price Correction Feature has been turned on". OKX runs the same idea from the other side, letting an API user opt IN to amendment through a pxAmendType field rather than taking the rejection. So even the consequence is a parameter.
If you take one operational thing from this piece, take that. A trading system that treats "order did not rest" as one error class will mis-handle at least one of these three venues.
What this changes when you are reading a fast market
Two more things, and neither of them requires you to trade differently.
First, the band is one of the reasons executed liquidation volume can look smaller than a naive model of the move predicts. A corridor that rejects far-away orders is, by construction, a constraint on how far a cascade can print in a single step on that venue.
Second, and most usefully for anyone comparing venues, band width is one visible output of a venue's risk configuration, and it sorts instruments in a way you can read for free. Bitcoin sits at 5% while the modal crypto perpetual on the same venue sits at 15%, and the equity and metal perpetuals sit tighter still at 3%. Read that ordering as a statement about liquidity and asset class rather than as one number you can carry between symbols.
How to check a venue's band yourself
The entire method is four requests and no credentials.
- Pull the instrument definition, not the ticker. Ask the venue for its instrument or exchange metadata for your exact symbol. The band lives with the contract specification, not with the price feed.
- Identify the shape. Decide whether you are holding a multiplier, a ratio, or an absolute price. If it is not already a price, you are only half done.
- Find the reference price the venue names in its own documentation for that field, and apply the coefficient the way the venue's own formula says to, not to the last trade you happen to see on a chart. On one of the three venues here that formula takes two references, not one.
- Re-pull it before you rely on it. These are per-symbol parameters under venue control. Treat any band figure older than your current session as a hypothesis.
Doing this once per venue is enough to permanently retire the idea that "the price band" is a single number. There is a second, better known constraint on the same order field: Athenum's explainer on bid-ask spread and tick size covers the minimum increment an order price may use, which constrains how precise a quote can be, where the band constrains how far away it may sit. For the other side of a fast market, Athenum's write-up on how liquidation cascades happen covers the forced selling that a corridor is partly designed to contain. Athenum aggregates derivatives data across the venues it covers, so the cross-venue views it publishes are built on each venue's own definitions rather than on one borrowed number.
The honest caveat
Everything above is a statement about order admission, not about safety. A published corridor does not promise you a fill, does not promise the reference price is right, and does not stop a market from moving as far as it wants over several steps. Venues also enforce controls this piece does not cover, including position and order-count limits, and some venues document additional protections in help-centre pages rather than in the API surface. The transferable habit is narrow and boring: before you assert what a venue's price band is, fetch it, note the date, and note the symbol. The number belongs to a contract on a day, and it is published precisely so that you never have to guess it.
Education only. Not investment advice. No buy or sell recommendation is made or implied.