# CometBFT replicates any state machine and lets you program the consensus steps

> CometBFT is the Go implementation of the Tendermint consensus algorithm, a Byzantine fault tolerant engine that runs an application state machine written in any language across many machines. ABCI++ is what distinguishes it from a plain blockchain client, and the version scheme is what teams should read before upgrading.

**cometbft/cometbft** — CometBFT: A distributed, Byzantine fault-tolerant, deterministic state machine replication engine. A fork and successor to Tendermint Core.

- Repository: https://github.com/cometbft/cometbft
- Website: https://docs.cosmos.network/cometbft
- Stars: 929 · Forks: 843
- Language: Go
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/cometbft-cometbft

## Consensus as middleware, not as a blockchain framework

CometBFT describes itself as Byzantine Fault Tolerant middleware that takes a state transition machine, written in any programming language, and securely replicates it on many machines. That sentence defines the boundary precisely. The engine handles agreement, gossip, block production and validation. Your application handles transactions and state. The two meet at an interface, so your state machine can be written in Rust, JavaScript or anything else, and the replication layer does not care.
The engine implements the Tendermint consensus algorithm and is a fork of Tendermint Core. The README claims speeds of up to 10k transactions per second, and states that CometBFT is the most widely adopted, battle tested consensus engine in blockchain today. Treat that figure as a claim in the README rather than as something measured here.
The audience is two groups. The first is blockchain teams writing a custom application and needing a consensus layer they can inspect and patch. The second is Cosmos ecosystem teams, since Cosmos Labs maintains CometBFT along with the Cosmos SDK, IBC and Cosmos EVM, and Cosmos Labs is a wholly owned subsidiary of the Interchain Foundation, a Swiss nonprofit.
For a plain database with a single writer, all of this is unnecessary. For a ledger where several operators must agree on the order of events without trusting each other, it is the component you cannot write yourself.

## ABCI++ puts programmability into every step of the engine

The feature the README singles out is ABCI++, described as the flagship feature, which enables developers to add programmability and customization to every step of the consensus engine. Everything else in the product description flows from that.
The application boundary is the abci/ directory at the root of the repository, with proxy/ sitting beside it. v0.38.x is the supported version line and it introduces ABCI 2.0, which implements the entirety of ABCI++. The CHANGELOG records breaking changes to public APIs, and the API surface is defined precisely: all publicly exposed types, functions and methods in non internal Go packages, plus the types and methods reachable through the CometBFT RPC interface.
That definition has a practical consequence. When you upgrade a MINOR version, you need to check two surfaces, the Go API you import and the RPC methods your clients call. A change in either counts as a breaking change and is documented in the CHANGELOG.
The README claims CometBFT is highly performant, and attributes its modularity to letting developers choose tools and technologies suited to a project. The practical version of that claim is that the engine does not impose a transaction format, an account model or a scripting language. Those choices belong to your application, which is the point of the separation.

## The directory layout is the architecture

The top level entries of the repository map almost one to one onto the stages of a node, which makes it a decent guide to the internals before you read any code.
The networking and consensus machinery sits in p2p/, consensus/, mempool/, blocksync/ and statesync/. Evidence handling lives in evidence/, the signing key machinery in privval/, and the peer to peer layer has both lp2p/ and the libp2p dependency in go.mod, with github.com/libp2p/go-libp2p v0.47.0 listed. The light/ directory holds the light client. Storage and state live in store/ and state/, the RPC surface in rpc/, the inspector tooling in inspect/, and the command line entry points in cmd/.
Two paths deserve a second look. consensus/ is where the Tendermint algorithm is implemented, and evidence/ is where the mechanism for reporting misbehaving validators lives, which is the part of a BFT system people underrate. privval/ holds the private validator, the key that signs blocks, which is deliberately separated from the rest of the node so it can be run as a separate signer.
The module path is github.com/cometbft/cometbft and the go directive is go 1.26.6. The dependency list also shows a Prometheus client, a Cobra and Viper configuration stack, a LevelDB store, a PostgreSQL driver at github.com/lib/pq v1.12.3, and the curve25519-voi and blst libraries, the latter being the pairing friendly cryptography used for BLS style operations.

## Running a local cluster with the bundled docker-compose file

The README points at two quick start paths, a single node guide and a local cluster using docker-compose. The compose file at the root of the repository defines four nodes on a bridge network.
```yaml
services:
  node0:
    container_name: node0
    image: "cometbft/localnode"
    ports:
      - "26656-26657:26656-26657"
    environment:
      - ID=0
      - LOG=${LOG:-cometbft.log}
    volumes:
      - ./build:/cometbft:Z
    networks:
      localnet:
        ipv4_address: 192.167.10.2
```
What this tells you is concrete. The image is cometbft/localnode, each node is given an ID through an environment variable, and the log file name falls back to cometbft.log unless you set LOG. The build directory is mounted into the container at /cometbft, which is where the node binary produced by the Makefile is expected to land.
The port mapping shifts per node so that several nodes can run on one host, with node0 taking 26656-26657 and node1 taking 26659-26660. The network subnet is 192.167.0.0/16 with fixed addresses from 192.167.10.2 upward, so a cluster of four nodes has a predictable layout.
The full file is the source of truth for the rest, since node2 and node3 follow the same pattern with their own IDs and ports.

## Building from source: the Makefile drives cross platform binaries

The Makefile includes common.mk and tests.mk and defines the build outputs.
```bash
PACKAGES=$(shell go list ./...)
BUILDDIR?=$(CURDIR)/build
OUTPUT?=$(BUILDDIR)/cometbft

CGO_ENABLED ?= 0
```
The default target is all, which runs build, test and install in that order. CGO is disabled by default, which matters because the project builds static binaries that run in minimal container images.
Cross compilation is driven by the GOOS, GOARCH and GOARM variables, with the Makefile rewriting them when a Docker TARGETPLATFORM is set.
```bash
TARGETPLATFORM ?=
GOOS ?= linux
GOARCH ?= amd64
GOARM ?=
```
Without a TARGETPLATFORM the binary is linux and amd64. When the variable resolves to linux/arm, the Makefile sets GOARCH to arm and GOARM to 7; linux/arm/v6 uses GOARM 6; linux/arm64 sets GOARCH arm64 with GOARM 7. The 386, mips, mipsle, mips64, mips64le and riscv64 cases are handled the same way, each rewriting the variables so the build matches the target platform.
The minimum Go version depends on the branch. The requirements table lists Go 1.26.6 or higher for main and Go 1.22 or higher for v0.38.x. The README also says explicitly that you should not depend on main as your production branch and should use releases instead, with the release process described in RELEASES.md.

## A MINOR bump can mean starting a new chain

This is the part of the README that deserves a close read, and the part teams are most likely to underestimate.
CometBFT uses Semantic Versioning, but with a twist to give 0.X.X users some stability: the MINOR version is used to signal breaking changes across the CometBFT API. Normally a MINOR bump is additive. Here it is a warning.
The consequence is stated plainly. The project does not guarantee that breaking changes, meaning bumps in the MINOR version, will work with existing CometBFT blockchains. In those cases you will have to start a new blockchain, or write something custom to get the old data into the new chain. Any bump in the PATCH version should be compatible with existing blockchain histories.
So the upgrade matrix is asymmetric. Patch releases are safe for a live chain. Minor releases can force a chain migration with custom work, and the data movement is on you. UPGRADING.md is the document to read before a minor bump, and CHANGELOG.md lists the breaking changes to the Go API and the RPC.
The alternative to absorbing that is to stay on a patch line. The supported versions list names v0.38.x, and the release trail shows parallel lines rather than a single trunk: v0.38.26 on 2026-08-13, v0.39.4 on 2026-07-28 and v0.40.0 on 2026-07-27. Three lines, three different major minors, all with recent releases.

## Apache 2 licence, maintained by Cosmos Labs, security handled through a bug bounty

The licence field on the repository says Apache-2.0, and a NOTICE file sits at the root of the tree. Apache 2 is permissive and includes an explicit patent grant, so it can be combined with proprietary applications, though the notice and attribution conditions in the licence text still apply to redistribution.
On people, the README is specific. Cosmos Labs maintains the core components of the stack, which are Cosmos SDK, CometBFT, IBC, Cosmos EVM and various developer tools and frameworks, and the detailed maintenance policy lives in the Cosmos security policy repository. Cosmos Labs also provides advisory and engineering services for blockchain solutions, and it is a wholly owned subsidiary of the Interchain Foundation, which handles treasury management, funds public goods and supports governance for Cosmos.
The repository is not archived and the last push was on 2026-10-22, so the codebase is receiving current work. Support for questions runs through Discord, Telegram and Slack, and the README states that the issue list is exclusively for bug reports and feature requests.
Security reports go through the Cosmos bug bounty program on HackerOne, with the kinds of bugs sought described in SECURITY.md. That is worth noting for an evaluation: a consensus engine is exactly the kind of software where a private disclosure channel matters more than a feature request tracker.

## Conclusion

Adopt CometBFT when you need Byzantine fault tolerant replication of an application that is not written in Go, and verify first that your chain can survive a MINOR version bump, since the project does not promise compatibility there. Do not adopt it if you want a self contained blockchain framework with accounts and modules, because that layer belongs to the Cosmos SDK rather than to CometBFT. Before running anything in production, pin a release tag rather than the main branch, and read UPGRADING.md before the upgrade.

## FAQ

### What is CometBFT and what does it do?

CometBFT is a Byzantine Fault Tolerant middleware written in Go that takes a state transition machine written in any programming language and securely replicates it on many machines. It implements the Tendermint consensus algorithm and is a fork of Tendermint Core.

### What is ABCI++ in CometBFT?

ABCI++ is described in the README as the flagship feature, which adds programmability and customization to every step of the consensus engine. CometBFT v0.38 introduces ABCI 2.0, which implements the entirety of ABCI++.

### How do I run a local CometBFT cluster for development?

The README links a quick start guide for a local cluster using docker-compose, and the repository ships a docker-compose.yml defining four nodes on a bridge network using the cometbft/localnode image with fixed IPs from 192.167.10.2.

### Is upgrading CometBFT safe for a running blockchain?

A PATCH version bump should be compatible with existing blockchain histories, but the project does not guarantee that MINOR version bumps will work with an existing chain. In those cases you will have to start a new blockchain or write custom code to move the old data across.

### Which Go version do I need for CometBFT?

The requirements table lists Go 1.26.6 or higher for the main branch and Go 1.22 or higher for v0.38.x. The README also advises not to depend on main as your production branch and to use the tagged releases instead.

## Sources

- [cometbft/cometbft on GitHub](https://github.com/cometbft/cometbft)
- [License: Apache-2.0](https://github.com/cometbft/cometbft/blob/main/LICENSE)
- [Project website](https://docs.cosmos.network/cometbft)
- [README](https://github.com/cometbft/cometbft/blob/main/README.md)
- [Releases](https://github.com/cometbft/cometbft/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cometbft-cometbft