// the find
cometbft/cometbft
CometBFT: A distributed, Byzantine fault-tolerant, deterministic state machine replication engine. A fork and successor to Tendermint Core.
CometBFT is the consensus engine underneath most Cosmos-ecosystem blockchains — it handles BFT state machine replication so your application just implements the ABCI interface and lets CometBFT deal with networking, voting, and finality. It's a production fork of Tendermint Core, now maintained by Cosmos Labs under the Interchain Foundation. If you're building a sovereign chain or need BFT consensus without writing your own Paxos/Raft implementation, this is the serious option.
ABCI++ (v0.38+) gives application developers hooks at every stage of consensus — ProcessProposal, PrepareProposal, ExtendVote — which means you can do things like order transactions by MEV priority or inject oracle data without forking the consensus layer itself. The ADR archive (100+ decision records) is genuinely useful: you can see exactly why each design choice was made, which is rare in infrastructure projects. Nightly fuzz and e2e test suites run against a multi-version cluster matrix, so cross-version upgrade safety is actually tested, not just promised. The separation between the consensus engine and the application via a socket/gRPC boundary means your app can be written in any language — Rust, Python, whatever — without touching the Go internals.
The versioning policy is honest to a fault: minor bumps can require starting a brand-new chain, and the team explicitly says they don't guarantee migration tooling. For anyone not already in the Cosmos ecosystem, the operational surface is steep — you're inheriting the full p2p networking stack, WAL management, state sync, and light client, all of which have their own failure modes that aren't well-documented outside of the ADRs. At only 896 stars the GitHub presence is misleading — the actual usage is through Cosmos SDK chains which never directly star CometBFT — but that also means most community knowledge lives in Cosmos-specific forums, not here. The config.toml surface is enormous and the documentation for production tuning (mempool limits, p2p settings, consensus timeouts) is scattered across multiple doc trees that don't always agree.