Ninjabot: Binance Trading Bot Setup and Backtesting

What Ninjabot solves for Go trading developers

Ninjabot addresses the gap between writing an isolated trading algorithm and connecting that algorithm to exchange data, orders, portfolio accounting, and repeated evaluation. The README describes it as a cryptocurrency trading bot framework implemented in Go for custom strategies in both spot and futures markets. Its intended users are developers who are comfortable defining trading rules in code and want the same strategy structure to support historical simulation, live paper trading, or an actual Binance account.

The project includes distinct paths for these modes. Historical data can be loaded from CSV for backtesting. The paper wallet example uses real-time data while keeping trading in simulation and includes a dashboard control panel. The spot and futures examples connect a custom strategy to Binance, with the futures example adding margin configuration.

This is a development framework, not a packaged strategy. Ninjabot does not supply an investment thesis, tell you which asset or timeframe to trade, or remove the need to assess a strategy's assumptions. Its disclaimer also says the software is for educational purposes and warns users not to risk money they cannot afford to lose. That boundary matters for adoption decisions.

Ninjabot's strategy, exchange, and storage structure

The repository layout separates the framework into packages for exchange access, strategies, indicators, orders, notifications, storage, services, and the web interface. The root package exposes the main Ninjabot types, while `exchange/` contains exchange integrations and `examples/` contains executable examples for each operating mode. That separation makes it possible to start from a documented example rather than invent the entire application structure.

The backtesting path is explicit: the CLI downloads candle data into CSV, and `examples/backtesting/backtesting.go` runs a strategy against historical data through a paper wallet. The output includes closed trades, wins, losses, hit rate, payoff, profit factor, System Quality Number, gross and net profit, trading fees, maximum drawdown, and a bootstrapped 95% confidence interval. These are simulation statistics calculated from the supplied candles and strategy behavior, not a promise about future exchange results.

For live use, the README points to separate Binance spot and futures examples. The futures example supports margin settings, while the README also documents short positions. The dependency list includes `github.com/adshao/go-binance/v2`, HTTP routing through `github.com/go-chi/chi/v5`, SQLite through `github.com/glebarez/sqlite`, and BuntDB. The `web/` directory and `ui/` package connect the dashboard and HTTP API to the Go binary.

Installing Ninjabot and running the first backtest

The README gives the Go installation command for the module. This command adds Ninjabot packages to the current Go environment. It does not create a Binance account, enable trading, or install the optional dashboard build tools.

go get -u github.com/rodrigo-brito/ninjabot/...

The repository's `go.mod` declares `go 1.23.0` and a `go1.24.3` toolchain, so the local Go installation and toolchain setup must be compatible with those declarations. The documented first execution runs the included backtesting example from the repository.

go run examples/backtesting/backtesting.go

The example is a real use path because it exercises a strategy against historical data and prints a results table plus return, confidence interval, wallet, fee, drawdown, and volume sections. The README also states that a dashboard is available at `http://localhost:8080` for the example output. Treat that as a local example behavior, not a general guarantee that every strategy or deployment exposes the same endpoint.

For newer candle data, the CLI can write a CSV first. The following downloads BTCUSDT candles for a fixed period from the futures market:

ninjabot download --pair BTCUSDT --timeframe 1h --start 2024-01-01 --end 2024-06-30 --output ./btc.csv --futures

The CLI requires `--pair`, `--timeframe`, and `--output`. If no date range is supplied, it downloads the last month according to the CLI documentation.

Paper trading before Binance spot or futures execution

The paper wallet example is the safer documented bridge between backtesting and a real account. It consumes real-time data but keeps execution in a simulated wallet, and the README says that it includes a dashboard control panel. This arrangement helps expose integration problems, such as strategy initialization, order handling, and dashboard interaction, without treating simulated results as live trading evidence.

The distinction between backtesting and paper trading matters. Backtesting reads a finite historical CSV and produces statistics for that dataset. Paper trading uses current market data, so its observations still do not model every production concern unless the surrounding bot handles them. The README does not document order reconciliation, failover behavior, credential storage, process supervision, or rollback, so those points must be checked in the implementation and deployment configuration before using real funds.

The live examples are intentionally separate. `examples/spotmarket/spot.go` targets a real Binance spot account, while `examples/futuremarket/futures.go` targets Binance futures and includes borrowed-exposure and margin settings. Moving from paper trading to either example changes the operational risk boundary. API permissions, market type, order semantics, and liquidation behavior must match the strategy being deployed.

Fees, notifications, dashboard, and exchange boundaries

Ninjabot includes trading-fee handling in its backtest reporting, with gross profit, fees, and net profit shown separately. This is useful because a strategy that looks profitable before costs can produce a different result after fees. The fee model still depends on the exchange rules and parameters configured for the run, so the example output should not be transferred directly to another market without checking those assumptions.

Notifications are a documented feature, including Telegram support. The HTTP API and bot control panel are exposed through the `service/`, `ui/`, and `web/` areas. The web dashboard is built with Bun, as shown by the Makefile targets `ui-install`, `ui-dev`, and `ui-build`. Building the UI has separate prerequisites from using the Go module, which is why the README's core `go get` command should not be read as a full frontend installation guide.

The exchange scope is narrower than the word cryptocurrency can imply. The README specifically names Binance spot and Binance futures examples and lists Binance as the platform in the project description. It does not document adapters for other exchanges. A team needing multi-exchange routing, custody across venues, or exchange-independent execution should look elsewhere or verify an adapter that is not documented here.

Ninjabot limitations and maintenance signals

The main limitation is that Ninjabot exposes trading machinery, not investment validation. Historical performance depends on the CSV, strategy rules, fee settings, and assumptions encoded by the example. A positive result for one period or pair does not establish that the strategy works across changing market conditions. The repository's own output includes confidence intervals and drawdown, which are more informative than gross profit alone, but they still describe the simulated sample.

There is also a meaningful operational boundary between the Go service and its web assets. The Makefile separates Go checks from Bun-based UI installation, linting, testing, and building. The root project also has generated web API types and a `generate-check` target. A deployment that modifies `ui/dto.go` or related frontend types must account for generation and build consistency.

The repository is not archived. Its last push was on 2026-09-01, and releases include `v0.5.1` on 2026-08-24 and `v0.5.0` on 2026-08-22. These facts indicate recent repository activity at the time of review, but they do not establish exchange compatibility, operational reliability, or the availability of new features. The MIT license permits use and modification under its terms, while users remain responsible for reviewing those terms and complying with exchange rules.

Ninjabot versus a managed Binance trading service

A managed trading service usually owns the deployment process, exchange connection, monitoring, and operational maintenance. The user supplies configuration or strategy parameters, but does not write and operate the Go application. That model trades implementation control for a smaller operational burden.

Ninjabot takes the opposite approach. It gives a Go developer direct control over strategy code, exchange integration examples, backtesting, paper trading, storage choices, notifications, and dashboard source. The trade-off is that the developer must understand the code and deployment model. The repository does not present itself as a hosted service, and the README does not claim responsibility for trading results. For a developer building a custom strategy workflow, that difference is the main reason to choose Ninjabot. For a user who only wants a configured bot and dashboard, a managed service may be the more appropriate abstraction if its exchange support and operational terms fit.

Editorial conclusion

Ninjabot fits developers who want to write Go strategies and evaluate them with historical candles before considering paper or live Binance execution. It is a poor fit for a managed trading service, a non-Go workflow, or a user who cannot operate and monitor exchange credentials and bot processes. Before adoption, inspect the strategy implementation, verify how orders and positions behave in paper mode, confirm that the required Go toolchain is available, and test the exact Binance spot or futures account permissions needed for the intended market.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rodrigo-brito/ninjabot on GitHub