Bitcoin ABC on GitHub holds release source only; development happens elsewhere

A Bitcoin Core fork that enables eCash

The README makes three relationships explicit in three short sections.

eCash is a digital currency enabling instant payments to anyone, anywhere, using peer-to-peer technology with no central authority, where managing transactions and issuing money are carried out collectively by the network. It is a descendant of Bitcoin.

Bitcoin ABC is the name of the open source software which enables the use of eCash, and it is a fork of the Bitcoin Core software project.

So the name is slightly confusing when you first meet it: Bitcoin ABC is not a Bitcoin implementation, it is the software for a different chain that inherited Bitcoin's code.

The goal statement is given in its own terms, describing sound money usable by everyone and a series of optimizations and protocol upgrades intended to enable peer-to-peer digital cash at scale.

What an engineer takes from all of this is that this is a full node implementation with an indexer attached. The node validates and serves the chain, and the surrounding infrastructure in this repository, the explorer, the faucet, the wallet, the Chronik indexer, is what makes the chain usable by people rather than only by other nodes.

That shape is worth knowing before reading the repository, because a directory listing full of web services is unusual for something you might have assumed was a chain daemon.

Development does not happen in this repository

One line in the Development Process section settles how to approach the whole repository.

This GitHub repository contains only source code of releases. Bitcoin ABC development takes place at reviews.bitcoinabc.org, and the contributing instructions point to a CONTRIBUTING file.

That is a fork-and-mirror arrangement, and it means two things.

First, the commit history here is not where work happens. If you clone to contribute, you are cloning the wrong place. The review site named in the README is where pull requests go.

Second, the repository's top level is the state of a release, not the state of the project. That is why the root looks the way it does, with a `depends/` directory for vendored dependency builds, `doc/` and `docs.e.cash.Dockerfile`, a `share/` directory for packaging assets, and `arcanist/` for the linting tool.

The presence of `.arclint` and an `arcanist/` directory tells you the project uses Facebook's Arcanist for linting, which is a long-standing part of the Bitcoin Core lineage. So the fork inherits not only the code but the tooling culture.

The release history shows the cadence. 0.33.13 on 2026-09-24, 0.34.0 on 2026-10-01 and 0.34.1 on 2026-10-12, with the last push on 2026-10-15. Three releases in three weeks, which is normal for a node implementation and means you should pin rather than track a branch.

The licence is MIT, with the terms in a COPYING file, and there is a SECURITY file for the disclosure policy.

Chronik is fourteen crates of indexing infrastructure

The Cargo workspace at the root is the clearest technical statement in the repository, because it names what the project actually builds alongside the node.

The workspace members include Chronik crates: `chronik-db`, `chronik-http`, `chronik-lib`, `chronik-indexer`, `chronik-bridge`, `chronik-plugin`, `chronik-plugin-common`, `chronik-plugin-impl`, `chronik-proto`, `chronik-util`, plus `abc-rust-error` and `abc-rust-lint` for errors and linting and `bitcoinsuite-core` and `bitcoinsuite-slp` as the library core.

The layering is conventional and readable. `chronik-db` is storage, `chronik-http` is the service surface, `chronik-lib` is the shared types, `chronik-indexer` is the ingestion, `chronik-bridge` connects to the node, and the three plugin crates are an extension interface with a common trait, an implementation and utilities. `chronik-proto` is the wire protocol between those pieces.

The module crates are the interesting boundary. `ecash-lib-wasm` and `avalanche-lib-wasm` are compiled to WebAssembly, and `ecash-secp256k1` with its own `ecash-secp256k1-sys` is the elliptic curve code, split into a safe wrapper and a system binding.

Compiling secp256k1 and a library to WebAssembly inside a node implementation is a significant design decision, because it implies the cryptography or the validation logic is meant to run in a browser. That is consistent with a chain that expects web wallets, and it explains why the JavaScript package exists.

There is also `apps/proof-manager-cli`, and two explorer binaries under `web/explorer/` named `explorer-exe` and `explorer-server`. So the web explorer is not a JavaScript application, it is a Rust binary with a server component.

The workspace sets `rust-version = 1.80.0`, so the minimum supported Rust version is pinned and checkable.

A release profile optimised for size, and two dozen Dockerfiles

Two build details in the repository are worth reading closely.

The first is the WebAssembly release profile:

[profile.release-wasm]
inherits = "release"
lto = true
opt-level = "z"

`opt-level = "z"` optimises for size rather than speed, and combined with link time optimisation that is the profile you choose when the artefact is downloaded over a network rather than run thousands of times per second. Since those artefacts are the WebAssembly modules, this profile tells you the project treats download size as the constraint.

The second is the list of Dockerfiles at the repository root, which is long enough to be a map of the deployed system.

There is a Dockerfile per service. `cashtab` for the web wallet, with three more for its variants: `cashtab-connect`, `cashtab-faucet` and a plain `cashtab`. There is `ecash-wallet` and `marlin-wallet`. There is `e.cash` and `docs.e.cash` and `charts.e.cash` for the documentation sites.

Then the infrastructure services: `explorer`, `faucet`, `token-server`, `notifications-server`, `ecash-herald`, `ecash-agora`, `chronik-client`, `metachronik` and a `mock-chronik-client` for testing.

Having a mock client checked in is a good sign, since it means the indexer can be developed against without a running chain.

There is also `b58-ts.Dockerfile`, which pins the b58 TypeScript library that the Arc lint and unit tooling depends on. That connects to package.json, which describes itself as the Bitcoin ABC monorepo dependencies used to version pin binaries needed for Arc lint and Arc unit of the JavaScript repositories.

That is a small and honest piece of infrastructure: a single package.json whose only job is to make a lint tool reproducible. The rest of its devDependencies are ESLint 9 with plugins for headers, jest and mocha, Prettier with the Tailwind plugin, Next.js 16 and c8 for coverage, and a pnpm workspace for all of it.

Editorial conclusion

Adopt the Chronik crates if you need to index eCash chain data in Rust, since they are a coherent workspace with a database, an HTTP layer and a bridge to the node. Skip this repository for development, because it states it contains only release source and that development happens at reviews.bitcoinabc.org. Verify first which release you want, since 0.34.0 and 0.34.1 were published within days of each other in October 2026.

Frequently asked questions

Official sources

1. Bitcoin-ABC/bitcoin-abc on GitHub
2. License: MIT
3. Project website
4. README
5. Releases