Binance -1015 Too many new orders during volatility: order count limits, not request weight

Our quoting bot keeps limit orders on both sides of a few spot books and moves them as the market moves. During a sharp move, it started getting rejections:

{"code":-1015,"msg":"Too many new orders; current limit is 100 orders per 10 SECOND."}

At the same time, X-MBX-USED-WEIGHT-1M was under 15 percent of its limit, so the request weight limiter we had built (see our post on 418 bans) saw no problem. For about 40 seconds the bot could not update its quotes, leaving stale orders in a fast market.

Reproducing it

The response headers on order requests include order counts:

X-MBX-ORDER-COUNT-10S: 100
X-MBX-ORDER-COUNT-1D: 41822

Our quote update logic, for every price tick that moved the fair value by more than a threshold, cancelled both orders on each of 6 symbols and placed new ones. In calm markets that was a few orders per second. In the fast move, ticks arrived several times per second per symbol and the bot tried to place 20 to 30 new orders per second.

What we ruled out

• Request weight. Separate limit, and well within bounds.
• IP-based limits. -1015 is an account-level order limit, so moving to another IP would not help.

Root cause

The exchange limits how many new orders an account can place per time window (for example per 10 seconds and per day), separately from request weight. Cancels do not count as new orders, but every replacement does. Our cancel-and-replace loop scaled order count with market volatility, exactly when quotes mattered most, and hit the 10-second limit.

What is happening under the hood

Exchanges publish order rate limits in exchangeInfo.rateLimits with type ORDERS, alongside REQUEST_WEIGHT and RAW_REQUESTS. Order count headers on responses report current usage per interval. Unfilled order counts may also be capped. Market makers and frequent requoting strategies hit order limits long before weight limits.

There are ways to change an order with less churn: some exchanges offer cancel-replace as one request, and order amendment features that reduce quantity or change attributes while keeping queue priority in some cases. Check the exact rules for the venue and order type.

Environment

Minimal reproduction

Place and cancel orders in a loop faster than the published order limit per 10 seconds; the exchange returns -1015.

The fix

1. An order-count limiter alongside the weight limiter. It enforces the limits from exchangeInfo with a safety margin and gives priority to risk-reducing actions:

class OrderBudget:
    def __init__(self, per_10s: int, safety: float = 0.8):
        self.capacity = int(per_10s * safety)
        self.events = collections.deque()

    def try_acquire(self, priority: str) -> bool:
        now = time.monotonic()
        while self.events and now - self.events[0] > 10:
            self.events.popleft()
        reserve = 0 if priority == "risk_reducing" else int(self.capacity * 0.2)
        if len(self.events) + 1 > self.capacity - reserve:
            return False
        self.events.append(now)
        return True

20 percent of the budget is reserved for orders that reduce risk, such as hedges and exits. Cancels are always allowed.

2. Less churn by design.

• A minimum time between requotes per symbol and side (250 ms), and requote only if the price moved by at least one tick and beyond a threshold.
• When the price moves away from our quote, cancel without replacing until the market settles, instead of chasing every tick.
• Use the exchange's cancel-replace request where suitable, which turns two calls into one, and order amendment for quantity reductions where the rules allow.

3. Sync with server counters. The limiter updates its view from X-MBX-ORDER-COUNT-10S on every order response, so restarts and other processes using the same account are accounted for.

4. Graceful degradation. When the budget is exhausted, the bot widens or pulls quotes rather than leaving stale prices in the book.

Alternatives and trade-offs

• Higher limits through exchange programs for market makers. Possible for some accounts; does not remove the need for a limiter.
• Fewer symbols per account. Splitting strategies across sub-accounts spreads limits, at the cost of more operational complexity. Check the exchange's rules on how limits apply to sub-accounts.

How to test the fix

Replay of the volatile period's market data through the bot in simulation counted orders per 10 seconds: peak 61 with the new rules, against 230 attempted before. Testnet runs with artificially fast tick replay confirmed no -1015 responses.

Confirming in production

• No -1015 errors over the following months, including several volatile sessions.
• Daily order count dropped by about 55 percent with no measurable change in fill rates.
• Stale-quote duration during fast moves fell, because the bot now pulls quotes instead of failing to replace them.

Regression guard

• Alert at 70 percent of any order count limit.
• Order count per minute on the main dashboard next to request weight.
• Simulation of high-volatility replays in CI for changes to quoting logic.

Security implications

Being unable to cancel or update orders in a fast market is a risk exposure. The reserved budget for risk-reducing orders and the "pull quotes when constrained" rule are risk controls. Trading keys have no withdrawal permission and are IP-restricted.

Prevention checklist

• Know both request weight and order count limits for your venue.
• Track order counts from response headers.
• Design quoting to limit churn: thresholds, minimum intervals, cancel without replace.
• Reserve capacity for risk-reducing orders.
• Degrade by pulling quotes, not by leaving stale ones.

References

• Binance Spot API, limits (order rate limits and headers) — https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits
• Binance Spot API error codes (-1015) — https://developers.binance.com/docs/binance-spot-api-docs/errors
• Binance Spot API trading endpoints (cancel-replace, amend) — https://developers.binance.com/docs/binance-spot-api-docs/rest-api/trading-endpoints