Hummingbot: a Python framework for running market-making and arbitrage bots across 140+ venues

The problem Hummingbot actually solves: order lifecycle plumbing, not alpha

A market-making or arbitrage strategy is mostly bookkeeping. You need to place a bid and an ask, track both fills, cancel the stale side when the mid moves, requote at a new spread, and reconcile what the exchange reports against what your process believes. Every exchange does this differently, and every exchange will eventually reject or partially fill something at the worst moment. Hummingbot's value proposition is that this layer is written once, in Python, against a common connector interface, so a strategy can be pointed at Binance or a DEX middleware without rewriting the order management code.

The README frames the audience explicitly: the project's stated mission is to democratize high-frequency trading by building a community of algorithmic traders and developers. The topics list on the repository (market-making, arbitrage, orderbook, quantitative-finance, hft) matches that framing. This is infrastructure for people who already have a view on how to quote a market, not a signal service. The README also states that Hummingbot users have generated over $34 billion in trading volume across 140+ unique trading venues. That figure is self-reported through the project's own reporting site, and it says nothing about whether any individual strategy was profitable. Treat it as a measure of install base, not of edge.

Who it is for, concretely: Python developers comfortable with conda environments and config files, running on a machine they control, who want to operate one strategy at a time against a specific venue and pair. Who it is not for: anyone who wants a hosted bot, anyone who cannot read Python well enough to debug a strategy that misbehaves at 3am, and anyone whose strategy needs sub-millisecond colocation. Hummingbot is a framework you run, not a service you subscribe to.

Three strategy abstractions and one execution primitive

The README lays out a layered model, and the layering is the most interesting design decision in the project. At the top are Scripts: single-file Python strategies, described as the easiest way to build and customize your own bot, with simple_pmm.py as the reference example. A script is a self-contained program that talks to the connector layer directly. If you want to understand what Hummingbot does at the lowest level a user is expected to touch, read that file.

In the middle are Controllers: reusable V2 strategies whose configs, per the README, can be backtested, deployed, and tuned live while running. The example given is pmm_mister.py, a full-featured market making controller. The distinction from scripts matters operationally. A controller separates the strategy logic from its parameters, so you can change a spread or an order amount on a running bot without restarting the process. That is the difference between a research artifact and something you can leave running.

At the bottom are Executors: self-contained building blocks that manage order lifecycles for common patterns. The README names position, DCA, grid, arbitrage, XEMM, TWAP, and LP, and points at position_executor as the example. This is where the actual order state machine lives. The data flow is therefore: a script or controller decides what it wants, and an executor decides how to get it done, including when to cancel and when to reprice. If you are evaluating whether Hummingbot fits, the executor set is the thing to read, because it defines which order patterns you get for free and which you will write yourself.

Above all of this sits Condor, described as the AI harness for building and running agentic strategies and bot instances, which connects LLM-powered decision-making to deterministic trade execution via the Hummingbot API, controlled through Telegram or a web dashboard. That is a separate repository, and it is the newest and least conventional part of the stack. The design intent is clear: keep execution deterministic, keep decision-making pluggable.

Getting a bot running: the hbot CLI, from paper trade to live keys

The recommended path is the hbot command-line interface, installed from source. The README states it requires Anaconda or Miniconda. The sequence is clone, then make install, which per the README creates the conda environment, builds extensions, and exposes the hbot CLI. Then conda activate hummingbot and hbot --help. To use hbot outside the conda environment, make link-cli adds it to the host PATH.

On first use, hbot prompts for a keystore password that encrypts exchange API keys. For non-interactive use, set HBOT_PASSWORD or pass --password-stdin. That detail is the one to internalize before anything else, because every scripted or agent-driven deployment depends on it.

The paper trading path requires no API keys at all, which is a genuinely useful property. The README gives these commands:

hbot create simple_pmm --name conf_paper_bot.yml --set exchange=binance_paper_trade --set trading_pair=BTC-USDT hbot start conf_paper_bot.yml hbot status hbot stop

The README states this simulates trading against live Binance market data. That is a stronger test than a historical backtest for latency-sensitive logic, because the order book you are reacting to is real, even if the fills are simulated.

Going live means storing keys and switching to a controller. The README's example:

hbot connect binance hbot create pmm_mister --name conf_my_bot.yml --set connector_name=binance --set trading_pair=BTC-USDT --set total_amount_quote=100 hbot start conf_my_bot.yml

Note the constraint stated twice in the README: one bot per install. That is a real architectural boundary, not a footnote. If you want to run five strategies, you are running five installs or five containers.

The Docker path mirrors the source path deliberately. make setup asks whether to include Gateway, the DEX middleware; make deploy starts the container; make link-cli installs a wrapper that dispatches hbot into the container, so the commands above are identical. The README notes you can skip the wrapper and use docker exec -it hummingbot hbot <command>. To dedicate the container to hbot rather than the interactive client, uncomment command: tail -f /dev/null in docker-compose.yml before make deploy.

The interactive client, Gateway, and the dev-versus-production split

The TUI is the older control surface and remains the Docker default. The README's instructions are make deploy followed by docker attach hummingbot, or from source, make install && make run. This is the mode most tutorials and community content were written against, and it is still the right choice if you want to watch order books and fills in real time while tuning a strategy by hand.

Gateway is the piece that connects Hummingbot to decentralized exchanges, and it is opt-in: you answer y to the Include Gateway prompt during make setup. The README states that with Gateway included, the client starts in development mode, which means unencrypted HTTP. For production HTTPS, use the DEV=false flag and run gateway generate-certs, with a link to the Gateway installation page for the full development-versus-production comparison.

This is the sharpest operational trap in the documentation. A default make setup with Gateway enabled produces a working but unencrypted middleware. It will function. Nothing will complain. If you are only paper trading or experimenting on a local machine, that is fine. If Gateway is proxying anything that touches real funds or private endpoints, the default is not the deployment you want, and the fix requires both the DEV=false flag and a certificate generation step. Anyone standing up a DEX-connected bot should decide which mode they are in before running make setup, not after.

Where Hummingbot is the wrong tool

The one-bot-per-install constraint is the limitation most likely to bite. The README states it plainly in both the paper and live examples. There is no documented supervisor that runs N strategies in one process. Scaling to a portfolio of strategies means scaling containers or conda environments, each with its own keystore, config, and log stream. For a hobbyist running one market-making strategy on one pair, this is irrelevant. For a desk that wants twenty strategies sharing a risk budget, it means you are building the orchestration layer yourself, and Hummingbot will not help you reconcile net exposure across those processes.

Second, the framework supplies no strategy. The README's own examples are a basic market making script and a full-featured market making controller. If your edge is in signal generation, Hummingbot is a large dependency to take on for order placement alone, and you may be better served by a thinner exchange SDK plus your own order state machine, especially if you only ever trade one venue.

Third, the LLM-facing layer is the least proven part of the stack. Condor is a separate repository, and the README describes it in a single paragraph. Nothing in the supplied material describes how its decisions are validated, what happens when the model emits a malformed order, or how you audit an agent's trading history. That does not mean it is broken. It means the documentation does not yet answer the questions a risk-conscious operator would ask, and you should not assume those answers exist.

Fourth, the README's volume figure is self-reported via the project's reporting site. It is not independently verified in the material provided, and it should not be read as evidence that the strategies shipped with Hummingbot are profitable.

How this differs from writing your own bot on a raw exchange SDK

The obvious alternative is not another bot framework. It is a thin exchange SDK (python-binance, ccxt, or a venue's own client) plus your own loop. The difference in approach is where the abstraction sits. A raw SDK gives you authenticated REST and websocket calls and nothing else. You write the order state machine, the reconnect logic, the partial-fill reconciliation, and the cancel-on-disconnect behaviour. That is more work, but every line of it is yours, and there is no framework between you and the exchange when something goes wrong.

Hummingbot inverts this. You accept the connector abstraction and the executor vocabulary, and in exchange you get order lifecycle management for patterns the project has already implemented: position, DCA, grid, arbitrage, XEMM, TWAP, and LP. You also get the paper trading mode, which is a meaningful amount of work to build yourself, since it requires mirroring live market data into a simulated matching process.

The trade-off is legibility. With a raw SDK, when a fill is wrong, you read your own code. With Hummingbot, you read your controller, then the executor, then the connector, and the bug may be in any of the three. The framework earns its keep when your strategy spans multiple venues or when you want the executor patterns off the shelf. It earns less when you trade one pair on one exchange with a simple rule, because then the abstraction is pure overhead. There is no universal answer here, but the question to ask is whether you would otherwise write an order state machine more than once. If yes, the framework pays for itself. If no, it may not.

Release cadence, upgrade cost, and the Apache-2.0 terms

The release history shows a steady cadence: v2.14.0 in April 2026, v2.15.0 in June, v2.16.0 in July, with the repository last pushed in September 2026. Roughly every six to nine weeks. That is frequent enough that pinning matters. If you install from master rather than a tagged release, you are tracking a moving target, and the README's install instructions clone the repository and run make install, which builds extensions from whatever is on the branch at that moment. For anything running real money, check out a tag.

Upgrade cost is not documented in the supplied material, and that is worth flagging as a gap. A framework that ships every two months will change controller parameters and executor behaviour over time, and the README does not describe a migration path for existing configs. The practical implication: keep your strategy configs in version control alongside the Hummingbot tag you tested them against, so an upgrade is a deliberate act rather than an accident.

The licence is Apache-2.0, which permits commercial use, modification, and redistribution, and includes an explicit patent grant. The README states the codebase is free and publicly available under that licence. Two things to note without offering legal advice: Apache-2.0 requires that you preserve copyright and licence notices in redistributed code, and it provides no warranty. If you fork Hummingbot into a proprietary trading system, the notice obligations still apply. If you are building on top of it internally without redistributing, the obligations are lighter. For anything beyond that, talk to a lawyer, because the licence text is the authority, not this paragraph.

Editorial conclusion

Adopt Hummingbot if you are a Python developer who already has a strategy thesis and wants a maintained execution layer with a real order lifecycle, or if you want to paper-trade against live Binance data before committing capital. Do not adopt it if you expect the framework to supply alpha, if you need to run many bots from one process, or if you want a managed service that handles key custody and uptime for you. Before deploying live capital, verify three things against your own setup: that the connector you need is actually present and healthy, that the controller you picked exposes the parameters you intend to tune, and that your keystore password handling works non-interactively via HBOT_PASSWORD or --password-stdin, because that is the path every scripted and agent-driven deployment depends on.

Official sources

1. hummingbot/hummingbot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases