GoCryptoTrader: a Go framework for multi-exchange crypto trading

What GoCryptoTrader solves, and for whom

Every exchange ships its own REST endpoints, its own websocket message shapes, its own rate limits and its own symbol naming. If you want to trade on five venues, you normally write five clients and maintain them as the venues change. GoCryptoTrader is an attempt to collapse that work into one Go module. The README describes it as "a cryptocurrency trading bot supporting multiple exchanges written in Golang", and the feature list backs that up: a unified API for exchange usage, REST support for all listed exchanges, websocket support where the exchange offers it, an HTTP rate limiter package, and packages for currency pairs, tickers and orderbooks. The audience is Go developers building trading infrastructure, not retail traders looking for a downloadable app. The repository layout confirms the framing: the top level holds engine, exchanges, backtester, portfolio, gctscript, gctrpc and database directories rather than a single application entry point. One caveat sits at the top of the README in bold: the bot is under development and is not ready for production. Treat that as the project's own statement about its maturity, not as modesty.

How the exchange abstraction actually works

The core idea is a common interface implemented per venue. Under exchanges/ each integration wraps the venue's REST calls and, where available, its websocket stream, and the engine consumes them through shared types. That is why the README can claim a unified API while the support table still records per-exchange gaps: Bitflyer and Lbank are marked Yes for REST but No for websocket, while Yobit is marked NA for websocket, meaning the exchange does not offer the feature. FIX API support is mostly NA, with Bitstamp, Coinbase, Deribit, Gemini and HitBTC marked No. Currency handling is deliberately broad: support for all exchange fiat and digital currencies with individual toggles. Configuration is a single JSON file, encrypted with AES256 according to the feature list. Beyond the library surface, the project exposes a gRPC service with a JSON RPC proxy, a gRPC client in cmd/gctcli, a scripting layer in gctscript built on the Tengo interpreter, and an event-driven backtester that runs strategies against historical or custom data. Database support covers Postgres and SQLite3. The architecture is therefore closer to a framework with a daemon attached than to a self-contained bot: you can drive it over gRPC, script it, or import the exchange packages directly into your own Go program.

Building GoCryptoTrader from source and running it once

There is no published binary in the repository, so the install path is a Go build. The README instructs you to install Go first, then clone the repository, build it, create a config directory and copy the example config into place. On Linux or macOS the sequence is:

git clone https://github.com/thrasher-corp/gocryptotrader.git
cd gocryptotrader
go build
mkdir ~/.gocryptotrader
cp config_example.json ~/.gocryptotrader/config.json

On Windows the same steps use the AppData path instead:

mkdir %AppData%\GoCryptoTrader
copy config_example.json %APPDATA%\GoCryptoTrader\config.json

After that the README says to make any necessary changes to config.json and run the gocryptotrader binary. The example config is the file you edit to enable exchanges and supply API credentials; the README does not document a separate credential store. If you prefer containers, the repository ships a Dockerfile and a docker-compose.yml that builds the daemon and publishes ports 9052 and 9053, with the image exposing the range 9050 to 9053. The Dockerfile copies config_example.json to config.json inside /root/.gocryptotrader and sets the entrypoint to /app/gocryptotrader. Two optional build tags change runtime behaviour: go build -tags=sonic_on swaps in the Sonic JSON library, and go build -tags=udecimal_on replaces shopspring/decimal with udecimal. The README warns that the udecimal tag changes decimal behaviour: it retains up to 19 fractional digits, truncates arithmetic and float conversion beyond that without an error, truncates division to 19 digits where the default build rounds to 16, and rejects fractional Pow exponents. Enable it only if you have read those differences.

The decimal tag is a real correctness boundary

The udecimal build deserves separate attention because it changes numbers rather than performance. Under udecimal, a non-zero result with a magnitude below 1e-19 becomes zero, silently, because arithmetic and float conversion truncate without returning an error. Parsing behaves differently from arithmetic: NewFromString rejects inputs that need more than 19 fractional digits, so the same value can fail at parse time but vanish at compute time depending on how it arrived. Division also diverges between builds: udecimal truncates to 19 fractional digits while the default shopspring build rounds to 16, so the last digits of a division can differ depending on which tag you compiled with. The representation changes too, from 16 bytes to 32 bytes per Decimal, and the binary encoding is not compatible with shopspring's. For a trading system, a silent truncation to zero on a small magnitude is the kind of behaviour you want to find in a test rather than in a fill report. The default build avoids this particular class of surprise, and the README does not present the tag as a drop-in upgrade.

Where GoCryptoTrader is the wrong tool

The README's own production warning is the first filter. Beyond it, the support table is the practical limit. If your venue is not listed among the twenty-two entries, you are writing the integration yourself, and the README notes that pull requests for exchanges outside the top-30-by-liquidity target are welcome but not guaranteed to be merged. If your strategy depends on websocket order book updates and your venue is marked No or NA for websocket, you are on REST polling, which interacts with the rate limiter in ways you will have to design around. FIX connectivity is largely absent, so latency-sensitive institutional routing is out of scope. There is also an operational cost that the feature list implies rather than states: a daemon, a config file, a database, optional gRPC and a scripting layer are four moving parts before you place a single order. A developer who wants to test one idea against one exchange will find the exchange packages usable on their own, but the full engine is heavier than that task needs.

How it differs from single-exchange bots and Python frameworks

The closest comparison in the search data is Passivbot, a grid and DCA bot. The difference is scope rather than quality. Passivbot is an opinionated strategy application: you configure its parameters and it trades. GoCryptoTrader is a framework: it gives you exchange clients, orderbook and ticker types, a rate limiter, a portfolio tracker, a backtester and a gRPC surface, and leaves the strategy to you, whether that is Go code, a Tengo script under gctscript, or an external process talking to the gRPC service. If you want a bot that runs a known strategy out of the box, the framework model is the wrong shape. If you want to build your own execution layer across several venues without rewriting five websocket clients, the abstraction is the point. The language choice matters too: Go's concurrency model suits many simultaneous websocket streams, and the README positions the project as a Golang library first. A Python framework will have a larger ecosystem of strategy notebooks and indicators; GoCryptoTrader's technical analysis comes from the separate gct-ta module in its dependency list, not from a broad indicator library inside the repository.

Licence, maintenance and upgrade cost

GoCryptoTrader is MIT licensed, which is permissive and imposes no copyleft obligation on your own code. That applies to the repository; it does not extend to the exchange APIs you connect to, each of which has its own terms, and the README does not survey them. On maintenance, the last push to master was on 2026-09-22, so the repository is being worked on. There are no recent releases, which means there is no tagged version to pin to and upgrades arrive as commits on master. The repository ships a Makefile with lint, test, build and install targets, a golangci-lint version pinned in the Makefile, and a CI workflow referenced by the build badge, so the project does expect contributors to run its checks. The practical upgrade cost is the config file: it is a single JSON document that you edit by hand, and the README does not document a migration path between versions. Back up your config before pulling, and read the decimal and Sonic tag notes if you build with either tag.

Editorial conclusion

Adopt GoCryptoTrader if you write Go and want one unified API across many exchanges, with a gRPC service, a backtester and scriptable strategies, and if you accept the README's own warning that the bot is under development and not ready for production. Skip it if you need a finished retail bot, a hosted dashboard or a no-code interface. Before committing, verify the exchange you need in the support table, check whether your exchange offers a websocket feed, and confirm the licence terms of every exchange API you plan to connect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. thrasher-corp/gocryptotrader on GitHub