Binance Futures gives every account a budget of 2,400 request-weight units per rolling minute, and a trading bot breaks that budget not by trading too much but by reading too much. Placing an order costs 1 unit. Polling your open orders costs 40. A bot that checks for fills by polling can spend its entire minute in 54 calls, get an HTTP 429, keep going, and have its IP banned — taking every other bot on that address down with it. The fix is a design choice, not a retry loop: stream fills instead of polling for them, and stop yourself at 90% of the limit rather than letting Binance stop you at 100%.
This is written from running an autotrader that places orders for many users across 500+ pairs from shared infrastructure, where a rate-limit ban is not one person's problem. The numbers below are the ones the bot actually enforces on itself.
The budget every futures bot lives inside
Binance does not count requests. It counts weight. Every endpoint carries a cost, and the account's REQUEST_WEIGHT limit — 2,400 per minute on Futures — is a cap on the total.
The window is sliding, not calendar. A request made 59 seconds ago still counts; one made 61 seconds ago has fallen out. This matters for bursts: spending 2,000 units in ten seconds does not reset at the top of the next minute. You wait for those entries to age out one by one.
The bot reads the actual limit from Binance's exchangeInfo endpoint at startup rather than hardcoding it, then applies a safety factor of 0.9. So it stops itself at 2,160, not 2,400. The remaining 240 units are headroom for retries, clock skew between the bot and the exchange, and the fact that Binance's count and yours will never agree to the unit.
Not every call costs the same
This is the table that decides whether a bot survives. The endpoints the bot uses, and what each costs:
- Place an order: 1
- Place an algo order (trailing take-profit): 1
- Set leverage or margin type: 1
- Open or refresh the listen key for the user-data stream: 1
- Read position risk: 5
- Read open algo orders: 5
- Read open orders: 40
Trading is cheap. Reading is expensive, and reading open orders is very expensive. The whole discipline of not getting banned comes down to that asymmetry.
Spend a full minute one way and you can place 2,160 orders. Spend it reading positions and you get 432 reads. Spend it polling open orders and you get 54 — less than one per second — before you are throttled.
How a home-built bot gets banned
The pattern is always the same. The bot places an order, then wants to know whether it filled. The obvious way is to ask: call the open-orders endpoint, see if the order is still there. Ask every second per symbol. With ten symbols that is 400 weight per second, or the whole minute's budget in six seconds.
Binance responds with HTTP 429 and error -1003, TOO_MANY_REQUESTS. A bot without a limiter does not notice and keeps asking. Binance treats continued requests after a 429 as abuse and returns HTTP 418: the IP is banned, initially for minutes, lengthening with each repeat.
The part people miss: the ban is per IP. If the bot shares a server or a home connection with anything else that talks to Binance, all of it is dead for the duration.
What happens before every request leaves the bot
The bot's limiter is a sliding-window budget. Before any request, it prunes entries older than sixty seconds, then asks whether the call's weight would push the window past 2,160. If it would, the bot logs a warning naming the reason, sleeps one second, prunes again, and rechecks — for as long as it takes. Only when the call fits does it send, recording one timestamp per unit of weight.
After the response, it reads Binance's used-weight header and reconciles. Binance's count is authoritative; if the two drift, the bot trusts the exchange.
The visible effect is a flat top. During a burst of signals the window climbs, hits 2,160, and holds there while the bot throttles itself; as old entries age past a minute, the line falls and the bot resumes. It never touches 2,400, so it never sees a 429.
Polling versus streaming
The limiter keeps a bot out of trouble. The design keeps it cheap. Binance offers a user-data WebSocket stream: open a listen key (weight 1), and the exchange pushes every fill and position change to you the moment it happens. No polling. No 40-weight reads to find out what you already could have been told.
That is how the bot learns about fills, and it is why a signal burst that would bankrupt a polling bot's budget costs a streaming bot almost nothing beyond the orders themselves. Position reads still happen — at weight 5, on a schedule — but the expensive open-orders read is reserved for reconciliation, not for discovery.
Cost that does not grow with symbol count is the property that lets one process trade 500+ pairs. A polling design scales linearly with symbols; a streaming design does not scale at all, in the good sense.
Symptoms that your bot is hitting the limit
If you run your own bot, these are the tells:
- HTTP 429 anywhere in the logs.
- Error -1003.
- Orders placed seconds after the signal instead of immediately — the limiter, or Binance, is making you wait.
- HTTP 418 and every request failing at once.
- A usage spike right after a restart, when the bot reads state it could have kept.
- Adding one more symbol makes everything worse. That is the polling signature.
Bursty signals against a polling design
Signals do not arrive evenly. In a volatile hour the model can fire on dozens of pairs in minutes, then go quiet. A polling bot hits its budget in the burst and is banned for the calm that follows. A streaming bot throttles briefly during the burst and recovers within the minute.
Even a well-designed bot spends most of a busy minute on reads, not orders — position risk and reconciliation — which is why the 90% ceiling matters. The orders are the cheap part; the safety factor protects the reads that keep the bot's picture of your account honest.
Where the bot stops itself, and where Binance stops you
Two ceilings. The bot's is 2,160 and produces a one-second sleep and a log line. Binance's is 2,400 and produces a 429, then a ban. The gap between them is the entire difference between a bot that occasionally waits and a bot that occasionally dies.
If you are evaluating any bot, this is a fair technical question to ask its operator: what is your request-weight ceiling, and how do you learn about fills? "We poll" and "we have never hit a limit" are both answers that tell you something.
The order limit is a separate budget
Request weight is not the only limit in exchangeInfo. Binance also publishes an ORDERS limit — a cap on the number of orders placed per short interval, independent of weight. A bot can be well under 2,400 weight and still trip it by firing a burst of entries, exits and stops in the same second, because each of those is an order.
The two limits fail differently. Weight exhaustion comes from reading; order exhaustion comes from a signal burst on many symbols at once. A bot that streams fills has solved the first and still has to pace the second, which is one more reason the entry, take-profit and stop are placed in sequence rather than all at once, and why a max-positions setting protects the bot's budget as much as your wallet.
The listen key has to be kept alive
The user-data stream is not free forever. The listen key that opens it expires unless the bot refreshes it, and Binance's rule is that a key left alone for an hour is dropped. A dropped key means the stream goes silent — fills stop arriving, the bot's picture of your account goes stale, and the next thing it does is fall back to expensive reads to find out what it missed.
So the bot refreshes the listen key on a schedule, at weight 1 each time. It is the cheapest request it makes and the one it can least afford to skip. If you ever see a bot's read weight spike for no visible reason, a lapsed listen key is the first thing to suspect.
What the bot logs when it throttles
Throttling is not silent. Each time the limiter holds a request, it writes a warning naming the reason the request was made, how much weight is already in the window, the ceiling, and how much the request needs. That is enough to tell, after the fact, whether a slow order was a burst of signals or a runaway read loop — the two look identical from the outside and have opposite fixes.
Why this matters more on shared infrastructure
A single user's bot on a home connection bans one person. A service placing orders for many users from shared servers cannot afford a single ban, because it would stop every user at once — during exactly the volatile stretch when the signals were firing. The limiter and the stream are not optimisations; they are what makes running many accounts from one place possible at all.
That is also why the bot deactivates a user on a bad API key rather than retrying: a rejected key retried forever is pure weight spent on a request that cannot succeed. And it is why an outage is survivable — the exits rest on the exchange, so a throttled or restarting bot does not leave a position unprotected.
What to take from this if you are choosing rather than building
You do not need to build any of this to benefit from knowing it. If you are deciding whether to use a bot, are crypto trading bots worth it is the honest overview, and connecting a bot to a Binance API key safely covers the permissions. Whether the engineering produces results shows up in one place: the live performance page, regenerated hourly, with expired signals counted against the hit rate. A bot that got banned mid-burst would show it as missed trades. Questions go to the bot at t.me/hafizebot.
Frequently asked questions
What is the Binance Futures API rate limit? 2,400 request-weight units per rolling 60-second window per account. Weight, not request count: placing an order costs 1, reading open orders costs 40.
What does error -1003 mean on Binance? TOO_MANY_REQUESTS, returned with HTTP 429 when your weight exceeds the limit. Keep sending after a 429 and Binance escalates to HTTP 418, an IP ban that lengthens with each repeat.
Why does polling open orders get bots banned? Because the call costs 40 weight. Fifty-four of them fill the whole minute. A bot polling per symbol per second exhausts its budget in seconds and, if it keeps going, is banned.
How does a bot find out about fills without polling? Through the user-data WebSocket stream. Opening a listen key costs 1 weight, and Binance then pushes every fill and position change as it happens.
Why stop at 90% of the limit instead of 100%? Because your count and Binance's will never agree exactly, retries cost weight, and clocks drift. The bot throttles itself at 2,160 so it never reaches the 2,400 where Binance throttles it.
Does a rate-limit ban affect my open positions? No. A ban stops new requests; existing positions and their resting take-profit and stop orders on Binance are unaffected.
Closing note
Rate limits do not break bots that trade a lot. They break bots that ask a lot. Stream what you can, budget what you must, and leave the last 10% alone.
None of this is investment advice. Cryptocurrency futures carry a high risk of loss; trade only with money you can afford to lose.