BBGO: a Go trading framework where the exchange abstraction is the product

Three audiences, and the README separates them on purpose

BBGO describes itself as a crypto trading bot framework written in Go, and the README splits its users into three groups rather than presenting one product. Trading bot users run the built-in strategies. Strategy developers use the trading unit and the back-test unit to write their own. Trading unit developers build on the underlying common exchange API, which currently covers eight major exchanges.

That framing matters for evaluating it. What looks like a feature list from the outside is three separable layers, and a given user may only ever touch one. Someone running grid strategies on Binance is not using the indicator library; someone writing a strategy on top of the exchange interface is not using the built-in strategies at all.

The project carries both an English and a Traditional Chinese README, and the topics list binance, bitcoin, crypto, cryptocurrency, trading and trading-bot. The homepage is bbgo.finance.

The indicator API is a pandas.Series imitation, and that is the differentiator

The longest part of the README is the indicator list, and the reason it is worth reading past the count is the interface. BBGO describes its indicators as having an interface similar to pandas.Series, with documentation links for both the series type and its usage. Each indicator is a file under pkg/indicator.

The list is broad enough to be a reference library rather than a strategy aid: moving averages in five variants including Hull, Tillson T3, Arnaud Legoux and Geometric; MACD, RSI, Stochastic Oscillator, Bollinger Bands, ATR and ATR Percentage, CCI, DMI, OBV, Parabolic SAR, Fisher Transform, Kalman Filter, G-H Filter, Klinger Oscillator, Linear Regression, SuperTrend, VWAP, VWMA, Volume Profile, Pivot points and Ehler's Super Smoother Filter among others.

If you are porting a Python research script, the Series interface is the bridge: expressions that compose a moving average with a standard deviation band can be transcribed rather than rewritten in a channel-per-value style.

Streaming is the difference between a bot and a poll loop

The infrastructure layer is where a framework earns its keep. BBGO provides an exchange abstraction interface so the same strategy code runs against different venues, stream integration for both user data and market data over websockets, and real-time order book integration through a websocket rather than a polled REST snapshot.

On top of that sit the parts that are tedious to write correctly. PnL calculation, so a session reports its own result rather than leaving you to reconstruct it from fills. TWAP order execution, documented separately under doc/topics. Slack and Telegram notification for state changes. Multi-exchange session support, described as connecting to more than two exchanges with different accounts or subaccounts, which is the requirement for the cross-exchange strategies later in the table.

Back-testing gets its own doc/topic file. The engine is KLine-based, which means it consumes candle data rather than tick data, and there is a built-in parameter optimization tool for sweeping a strategy's inputs.

The grid strategies need inventory you supply, and the README says so

The built-in strategy table is the most useful section for a decision, because it names the backtest support column and leaves it empty for the grid strategies. Grid is described as the first generation, more flexible, but requiring you to prepare inventories. Grid2 is the second generation, able to convert your quote asset into a grid, supporting base+quote mode. Bollgrid pairs the grid layout with the built-in Bollinger indicator.

All three are typed as maker strategies. The blank backtest support cells mean you cannot verify these against historical data in the framework, which is a significant constraint for anything with inventory requirements.

The cross-exchange makers are the opposite case. xmaker is cross-exchange market making that hedges inventory risk on the other side, xdepthmaker is depth-based, and xfixedmaker uses a fixed spread. xmaker is explicitly marked as having no backtest support, consistent with a strategy whose correctness depends on two live books rather than on history.

Building: a Makefile with web tags, or a Docker image

There is no installation snippet in the README excerpt, so the buildable artefacts are the honest reference. The Makefile cross-compiles for linux and darwin on both amd64 and arm64, and distinguishes a full build from a slim one. The full build uses build tags web,release and depends on pkg/server/assets.go; the slim build drops the web tag.

go build -tags web,release -o $(BIN_DIR)/bbgo ./cmd/bbgo

The distinction is about size and asset embedding, not features. A slim binary has no embedded dashboard; a full one carries the frontend assets.

The Dockerfile shows the container shape. It builds on golang:1.27-alpine3.24, needs gcc because of the SQLite driver, and produces a runtime image on alpine:3.24 that runs as a non-root user named bbgo. The default command is the one most deployments want.

ENTRYPOINT ["/usr/local/bin/bbgo"]
CMD ["run", "--config", "/config/bbgo.yaml", "--no-compile", "--no-sync"]

go.mod requires Go 1.27.2 and declares the Heroku install target for ./cmd/bbgo at the top, which explains the app.json and Procfile in the repository root.

Precision is opt-in, and that is a decision you have to make deliberately

The README lists high precision float point, up to 16 digits, with the instruction to run with -tags dnum. The default build therefore does not have it. Crypto exchanges quote prices and quantities in decimal, and a framework that computes positions in binary floating point accumulates representation error that shows up as PnL that does not reconcile.

The flag is easy to miss because it lives in a feature bullet rather than in a configuration section. Anyone deploying this with a fixed-precision accounting requirement should add dnum to the build tags alongside web,release and verify the behaviour against small order sizes first.

Precision is the one place where the framework makes a default choice for you that a financial system should not delegate.

State lives in a database, and there are two of them

The repository root carries bbgo.sql, a migrations directory, and rockhopper_mysql.yaml and rockhopper_sqlite.yaml. Rockhopper is the migration library, pinned in go.mod as github.com/c9s/rockhopper/v2. Two compose-style files means two supported database targets for the persistent state: MySQL and SQLite.

The same pattern appears in the dashboard side. apps/ contains the frontend, and the Makefile names apps/frontend/out as the frontend export directory and apps/backtest-report/out as the backtest report export directory, with a React-powered web dashboard listed as a feature and screenshots of both the dashboard and a backtest report.

There is also a desktop/ directory and an OSX_APP_NAME of BBGO.app in the Makefile, with the GUI defaulting to webview rather than lorca. That is a packaging detail, but it tells you the project has an opinion about being a desktop application as well as a server.

Two release lines, and an AGPL licence that constrains how you deploy it

The repository is not archived and the last push was on 2026-10-16. Releases, however, are irregular: bbgo-0.4.6 on 2026-04-14, then v1.63.0 on 2025-07-15 and v1.62.2 on 2025-04-22. Two distinct naming schemes in the release list, 0.4.6 and 1.63.0, suggest separate components or lines, so pinning needs care.

The licence is AGPL-3.0, and for a trading bot that is not a formality. AGPL's network clause means that if you run a modified BBGO as a service for other people, you owe them the corresponding source. For a self-hosted bot on your own account that clause generally does not bite. For anyone embedding BBGO into a hosted trading platform or a managed bot product, it is the constraint that decides the architecture, and you should settle it before building on top of it.

Configuration is YAML. The README links a skeleton config for the HeikinAshi versus normal OHLC choice, and there is a.env.local.example at the root for credential setup.

Editorial conclusion

Use BBGO if you want to write your own strategies in Go and need one exchange abstraction instead of eight client libraries, since the trading unit and back-test unit are the parts meant for strategy developers. Do not use it if you want a passive grid running unattended on day one, because the README marks grid and grid2 as backtest-unsupported and the first-generation grid requires you to prepare the inventory yourself. Verify first which of the eight supported exchanges your strategy needs, and confirm the dnum build tag if you care about decimal precision, since the default build is binary floating point and the 16-digit mode is opt-in.

Frequently asked questions

Official sources

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