Introduction
What is Hummingbot?
Hummingbot is one of the best open-source engines out there for algo trading today.
That said, it does have some quirks. One of which is the lack of satisfactory built-in backtesting and strategy optimization tools. Recently, the Hummingbot Foundation has started working on a repository for hypothesis testing (Quants Lab), but as of early 2026, I prefer to rely on a more advanced custom framework for optimizing strategies using PBT (Population Based Training, from AI training experience).
Even with its flaws, Hummingbot is a mature project.
It’s crucial that the funds you put under the bot’s control are safe, and you won’t lose them over a small bug in unfinished code.
Developers who already use Hummingbot as a trading framework have encountered many of these minor issues and have fixed them.
So, for now, I choose to use this framework as a base for production deployment of my bots.
Fix some issues
Hummingbot has individual rules for each Centralized Exchange (CEX), like Binance. During development, I noticed some inconsistencies in the rules for the MexC exchange, which I’ll share in this research.
MexC Rate Limits Research
Deep Codebase Analysis
GitHub Collaboration
How are MexC limits currently declared in Hummingbot?
(The general antispam threshold is omitted in the diagram)
How are MexC limits actually structured?
Official MEXC API Docs / Limits Description:
«According to the ==two modes of IP and UID (account)== limit, ==each are independent.==”» «Endpoints are marked according to IP or UID limit and their corresponding weight value.» «==Each endpoint== with IP limits has an ==independent 500 every 10 second== limit.» «==Each endpoint== with UID limits has an ==independent 500 every 10 second== limit.»
At first glance, it may seem that each endpoint can only have one Rate Limit Pool of the two: either the IP Pool or the UID Pool. However, the MEXC developers themselves assign both weights to some methods:
«Weight(IP): 1, Weight(UID): 1» (New order method)
This clearly demonstrates that endpoints can actually have both limits at once. An error 429 occurs as soon as one of them is exhausted; otherwise, the UID (account) rate limit would lose its purpose, as it could be bypassed using proxy networks (physical IP rotation).
It is also mentioned that the UID Pool only exists for those endpoints that require API keys to be used
«The account is used as the basic unit of speed limit for the endpoints that need to carry access keys»
It is noted that you can simultaneously have a maximum of 60 listen keys for WebSocket subscriptions (a listen key can be obtained via POST /api/v3/userDataStream):
«Each UID can apply for a maximum of 60 listen keys (excluding invalid listen keys). Each listen key maximum support 5 websocket connection (which means each uid can applies for a maximum of 60 listen keys and 300 ws links).»
At the same time, for the Listen Keys endpoint methods (/api/v3/userDataStream), standard UID / IP limits are not specified.
Let’s outline the identified differences between the current description of limits in Hummingbot and the real structure of limiting in MEXC:
-
A shared pool for limits does not exist — instead, each endpoint receives its own independent 500 points per pool every 10 seconds
-
Each individual endpoint requiring API keys has 2 pools at once — UID (500 units / 10 sec) and IP (500 units / 10 sec). An error 429 is returned as soon as one of them is exhausted.
-
Other (public) endpoints cannot have a UID Pool because they do not require API keys (they have only one pool — the IP Pool).
-
The /api/v3/order endpoint has a weight of 2 if used with the
GETmethod (Order status), but it has a weight of 1 if used with thePOST(New order) orDELETE(Cancel order) methods.
The real internal structure of MexC limits (diagram):
mexc Rate Limits (real, without antispam requests treshould).canvas
Research results
Excluding multi-account scenarios:
- The server (one public IP) handles no external accounts;
- We trade solely using our own account.

Simplified diagram:
(mexc Rate Limits (real, 1 account).canvas)