banbot: an event-driven Go framework for crypto strategy development and trading

What banbot is: one codebase for backtest and live execution

banbot is described as a high-performance, easy-to-use, multi-symbol, multi-strategy, multi-period, multi-account event-driven trading bot, and the feature list expands on that in the way that matters for a framework rather than a script.

The web UI entry says it all: write strategy, backtest, and deploy without IDE. That is the pitch. A strategy author edits code in a browser form, the framework runs it against historical data, and the same code is then pointed at a live account. The easy-to-use line says the same thing differently: write once, support both backtesting and real trading.

That single-codebase property is the design centre of the project, and it is also the source of its most common failure mode in frameworks of this kind. A strategy that behaves differently in replay than in live is a bug in the framework or in the strategy, and the only way to know which is to run the same code both ways. banbot is built so that this is the default.

The other feature lines describe the axes of variation: flexible, free combination of symbols, strategies and time frames; scalable, trade multiple exchange accounts simultaneously; high-performance, backtest for 1 year klines in seconds; and event-driven, no lookahead, more freedom to implement your trade ideas.

The last of those deserves emphasis. No lookahead means the framework will not let a strategy see data it could not have had at the time of the bar it is reacting to, which is the single most common way a backtest flatters a strategy that does not work live.

The audience is a developer comfortable with Go who wants to research and deploy systematic crypto strategies, not a trader looking for a prebuilt signal service.

The two strategy engines and what the factor one still needs

The most substantial part of the readme is the strategy engines section, and it describes a recent and significant restructuring.

There are two engines, selected with run_policy.engine. The default is time_series, which gives per-symbol callbacks, the shape most retail strategies are written in. The other is factor, for native multi-factor and cross-sectional rounds, where a strategy sees all symbols at once rather than one symbol at a time.

Both run from the same root commands, banbot backtest and banbot trade, and from one YAML configuration. The readme is specific about the sub-commands: mixed replay uses execution.mode: events together with explicit account budgets, factor research uses the root research command, version archives use data archive, and standalone expressions use the root validate and explain --spec commands. The English and Chinese guides and the API pages under bandoc/ are the reference, along with a refactor record at doc/strategy_engine_refactor.md.

The caveat about factor live trading is the most useful sentence in the readme for an evaluator. Factor live needs application-registered verified transport, instrument, revision and funding evidence, and startup reconciliation. Missing capabilities fail explicitly, and SDK support alone does not prove real factor venue readiness. Paper or dry-run is separate historical simulation.

That is an unusually candid statement. The factor engine is the research-facing half of the framework, and the readme is saying that running it live requires exchange-side registrations and evidence that the SDK alone cannot establish. For a user, it means the factor path is usable for research and for replay, and the live path needs venue work that is not yet done.

The configuration story is also stated with care. Configuration retains the v0.5 root keys without requiring a version marker, and ordinary loading leaves YAML unchanged, while explicit run_policy[].engine enables the new options, factor fields belong directly to each policy, and account execution overrides live at root accounts.<name>.

Exchanges come from banexg, and the web UI is a real part of the product

The exchange support is delegated, and the readme says so directly: banbot supports exchanges powered by banexg. The table lists the connectors with their market types, a version column and a websocket column. Binance, OKX and Bybit each appear with spot, usd-m and coin-m markets and websocket support marked Y.

Delegating that layer is a good architectural decision rather than a shortcut. Exchange APIs change, the market data formats differ, and the websocket reconnect logic is where most bots waste their time. Keeping that in a separate project means banbot can be about strategy, backtest and execution, and the readme's own topic list includes a binance-trader framing that suggests the connector set is where the exchange-specific knowledge sits.

The web UI deserves more attention than a feature bullet usually gets. Write strategy, backtest, and deploy without IDE is the first line of the list, and the documentation shows a UI development gif. For a framework whose users are quant developers, a browser-based strategy editor changes the adoption curve: it removes the IDE, the local Python environment and the notebook workflow from the loop.

The other major component is hyper opt, with support for bayes, tpe, random, cmaes, ipop-cmaes and bipop-cmaes. That is a parameter search layer, and the go.mod shows the underlying implementations, including go-bayesopt for the Bayesian method and c-bata/goptuna for the others.

The rest of the dependency list is the real signal about what this is: a Go web framework (gofiber), Postgres and SQLite drivers, gRPC and protobuf for what is presumably the internal service layer, a Telegram bot library, a websocket library, cobra for the CLI, decimal arithmetic from shopspring, gonum for numerics, and an Excel writer. It is a full application, not a library.

Getting started, and the AI-assisted workflow built into the repo

The quick start is short and delegates the setup to another repository:

go [runbanbot](https://github.com/banbox/runbanbot) to get started with Docker in minutes!

So the intended entry point is a separate launcher project, runbanbot, that gets you a Docker environment with banbot in it. The banbot repository itself carries a docker/ directory, and the top-level tree shows the scale of the application: cmd/, core/, biz/, com/, config/, data/, execution/, factor/, live/, llm/, opt/, orm/, rpc/, runtime/, runtimeplan/, strat/, web/, bandoc/ and more.

The web/ and llm/ directories are worth noting, and the readme's Work with AI section describes a workflow that is unusual to find documented.

Download the [banbot.md](doc/banbot.md) file, then attach this file to any AI conversation to tell it the strategy you want to test.

There is a Chinese version at doc/banbot_cn.md, and the alternative route is the Banbot Workflow page on the project website, which the readme offers for immediately testing an idea. So the intended path for a newcomer is to describe a strategy in natural language, let an assistant produce the strategy code against the documented API, and test it in the web UI before deploying.

That is a coherent answer to the write strategy, backtest and deploy without IDE claim, and it is also a risk worth naming. Generated strategy code that has not been read by a human is exactly the kind of code that looks right in a backtest and loses money live. The framework's own protections, the no-lookahead guarantee and the shared backtest and live path, help, but they do not substitute for reading the strategy you are about to run.

For contribution, the readme points to doc/contribute.md and to the Discord server for discussing development, new features and the roadmap.

The licence is the real decision, and it is dual

The licence section is where a reader who is not a trader still needs to pay attention, because this is commercial software in all but name.

The project is dual-licensed under the GNU AGPLv3 licence and a commercial licence. For free use and modifications of the code, you can use the AGPLv3 licence. If you require a commercial licence with different terms, please contact the author.

The AGPL half is the strict one. Its trigger is network use: if you modify the code and run it as a service that users interact with over a network, you owe those users the corresponding source of your modified version. For a trading bot that you run for yourself, that is not a problem. For a bot you run as a hosted platform for other people, it is a decision that needs legal review rather than a technical one.

The contribution terms are consistent with that and unusually explicit. Unless you explicitly state otherwise, any contributions intentionally submitted for inclusion in a banbot workspace you create shall be licensed under AGPLv3, without any additional terms or conditions. So your strategy code written in the web UI workspace is AGPL by default, unless you say otherwise explicitly, and the readme points to the commercial licence route for teams that need different terms.

The project also runs a donation page with BTC and ETH addresses, which is the norm for a project that is free to use but depends on a small number of people maintaining it. That is worth considering alongside the dual licensing: a project that sells a commercial licence is not going to disappear, but it is also not going to be driven by a community the way an AGPL-only project might be.

The repository is not archived and the last push was on 2026-10-15, with v0.6.0 released the same day after a v0.6.0-beta.11 and v0.6.0-beta.10 on 2026-10-11, so the 0.6 line is settling.

What to check before you point this at real money

The readme is instructive about what it does not guarantee, and an evaluator should read those parts twice.

First, the factor live path. Missing capabilities fail explicitly, and SDK support alone does not prove real factor venue readiness, which means a strategy that backtests beautifully under the factor engine may still refuse to trade live until the application registration, instrument, revision and funding evidence, and startup reconciliation are in place. That is a deliberate fail-fast design, and it is much better than a bot that silently trades the wrong instruments.

Second, the division between paper and live. Paper or dry-run is separate historical simulation, so a dry run tells you about the strategy logic, not about the execution path. The readme's mixed replay mode with explicit account budgets is a step further than a plain backtest, since it replays events, but a replay is still not a live account.

Third, the deployment path. The quick start is Docker, and the runbanbot launcher is the recommended route, which means the environment is a container rather than a Go toolchain on your workstation. That is good for reproducibility and for running several strategies side by side, and it means the strategy code, the configuration and the account credentials all live somewhere you have to think about.

The go.mod also sets a high toolchain floor, with go 1.26.0 and toolchain go1.26.8, so building from source needs a current Go installation.

What none of this can substitute for is reading the strategy. The no-lookahead guarantee protects the backtest from a specific class of lie, and the shared backtest and live code path protects the deployment from a class of drift, but a strategy with no edge will lose money identically in both.

Editorial conclusion

banbot fits a developer who wants one codebase to go from strategy idea to backtest to live crypto trading, with a web UI for iteration and a YAML file for deployment, and it does not fit someone who needs a broker-agnostic research environment or a guaranteed live execution path for factor strategies. Before running anything against real funds, read the factor live requirements in the readme, backtest on historical data with the same engine you intend to trade with, and confirm the strategy authorising mechanism and account budget settings your exchange connector expects.

Frequently asked questions

Official sources

1. banbox/banbot on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases