BitShares Core, the node and command-line wallet behind the chain

Chain software, with the wallet UI deliberately elsewhere

This repository is the BitShares blockchain node software and the command-line wallet software, written in C++. What it is not is the thing most people picture when they hear the name of a wallet, and the README makes that separation explicit by pointing to BitShares UI for the browser-based wallet and the desktop wallet. That split defines the audience. A node operator running a full node, a developer writing against the chain APIs, and a person who prefers a command line over a browser extension are the intended users. The node and the wallet share a codebase, which is why a single build produces both binaries. Around it the README points at several other resources, including a developer documentation portal, a user-facing documentation site, a wiki, a community forum, and the Awesome BitShares list for chat groups, client libraries and extended APIs. That last one matters for the next section, because the node exposes only part of the API surface.

Four branches, each built on the same matrix

The build table in the README is the clearest picture of how this project is maintained. Four branches are listed, master, develop, hardfork and testnet, and each one carries five status badges for the same set of workflows: a macOS build and test, an Ubuntu debug build and test, an Ubuntu release build and test, a Windows build and test, and a Docker build. The fifth row is master of bitshares-fc, the underlying framework library, which is built by the same organisation and appears in the table as a separate repository with its own macOS, Ubuntu debug and Ubuntu release workflows. The default branch of this repository is develop, so a clone without arguments gives you the integration branch rather than the release branch. The.gitmodules file and the submodule handling in the container build show that bitshares-fc is consumed as a git submodule, which means a source build is not a single repository checkout. Anyone maintaining a node has to decide which branch to track, and the answer changes what the node does.

Building the node and the wallet

The README recommends building on Ubuntu 24.04 LTS 64-bit, and it also says that prebuilt binaries can be found on the releases page for download, which is the faster path for an operator who does not need to compile. The source build goes through CMake and produces the node, the wallet and a developer key helper, which is what the container image does explicitly.

cmake \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_C_COMPILER_LAUNCHER=ccache \
    -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
    -DGRAPHENE_DISABLE_UNITY_BUILD=ON \
    . && \
make witness_node cli_wallet get_dev_key

Three flags do real work here. The Release build type is the obvious one. The two compiler launcher flags route compilation through ccache, which matters because a C++ codebase of this size recompiles a lot during development. The third, GRAPHENE_DISABLE_UNITY_BUILD, turns off unity builds, which speeds up compilation of the changed files at the cost of a longer full build. The three make targets are the three artefacts: the witness node binary, the command-line wallet, and the get_dev_key tool that produces a development key. The dependency list in the container image is long and specific, including the ncurses, bzip2, zstd, lzma and zlib development packages, curl and OpenSSL, and a set of Boost components covering threads, iostreams, date-time, system, filesystem, program options, chrono, test, context, regex and coroutine, plus autoconf, libtool and doxygen.

The container build handles the submodule mess

The Dockerfile is not a thin wrapper around a build script, it encodes the practical problem of building a project with git submodules on a machine that does not have them checked out correctly. The image is based on phusion/baseimage:noble-1.0.2, sets LANG to en_US.UTF-8, and configures ccache through environment variables including the compression flag and a sloppiness list. The build step first tries git submodule sync --recursive, and if that fails it falls back to walking the tree for .git directories and rewriting the submodule paths in the configuration files by hand, then syncing again. Only after that does it run git submodule update --init --recursive, configure with CMake and run the make targets. The ccache mount is a build cache declared as a Docker cache mount, so repeated builds reuse compiled objects. The repository also carries a docker/ directory and a README-docker.md, so the container workflow is a supported path rather than an afterthought, and the build-docker workflow badge appears for every branch.

Built-in APIs and the node API sets you can restrict

The README has two dedicated sections that matter more to an operator than the build instructions. One is titled Using Built-In APIs and the other is titled Accessing restrictable node API sets. The distinction is the important part. A node serves a set of API groups, and some of those groups are restrictable, which means an operator can turn off the endpoints a public node does not need to expose. Anyone running a public endpoint has to make that decision, and a node left with its full default set is a node serving more surface than intended. The README also points at the Awesome BitShares repository for extended APIs, which tells you the built-in set is the baseline and that more is available from outside this codebase. The developer documentation portal and the wiki are where the endpoint list itself lives, so the operational detail of which group does what is not in the README. For a team integrating with the chain, that separation is reasonable, but it means the API surface is a documentation task rather than a code reading task.

Suez 7.0.3, a testnet tag, and a three year gap

The release naming carries the network with it. The newest release is 7.0.3, titled BitShares Suez 7.0.3, published on 2026-09-10, and the same day a testnet build tagged test-7.0.5 appeared. The previous release, 7.0.2, was published on 2023-12-15, so the gap between the two 7.0 releases is close to three years, with the work accumulating on branches in between. The repository is not archived and the last push was on 2026-10-03, so development continues after the release tag. The licensing situation is the part that needs attention. The repository carries a LICENSE.txt, and GitHub could not classify it as a standard licence, which means the terms are in a custom document rather than a recognised permissive or copyleft licence. That is not a defect on its own, but it is a compliance task: a company running a scanner against its dependencies will get no answer for this one, and somebody has to read the file and decide.

Where the CLI wallet and the node stop being the right tool

The first limit is scope. If what you need is a wallet for a person rather than an account, the command-line wallet is the wrong shape and the browser or desktop wallet in the separate UI repository is the one to look at. The difference in approach is real rather than cosmetic, because the UI repository is a client of the same node APIs, so a person can point a browser wallet at your own node without running any of this C++ code at all. The second limit is operational. A source build needs a specific operating system, a compiler, a long Boost dependency set and a working submodule checkout, and if you skip the container route you inherit that setup. The third is the release cadence. A chain that shipped 7.0.2 at the end of 2023 and 7.0.3 in September 2026 is a chain where a node upgrade is a scheduled event with a long preparation window, not a routine pull, and a team that expects monthly releases from this repository will be disappointed. A hardfork branch in the table is another signal that consensus-affecting changes are planned on their own timeline, and that a node operator has to follow that plan rather than deploy whatever is newest.

Editorial conclusion

BitShares Core fits a node operator who wants to run the chain themselves, a developer building against the built-in APIs, or a team that needs a container image rather than a source build. It does not fit an end user who wants a graphical wallet, because the browser and desktop wallets live in a separate repository, and it does not fit an organisation that needs its licence to be readable by a standard scanner, since the licence file is custom. Verify three things before you commit a machine to it: the release you are pinning, because 7.0.2 and 7.0.3 are three years apart, the branch you build, since develop is the default and hardfork and testnet exist alongside master, and the contents of LICENSE.txt against your own compliance requirements.

Frequently asked questions

Official sources

1. bitshares/bitshares-core on GitHub
2. Issues
3. Project website
4. README
5. Releases