locabft — CometBFT fork by Locality Network

This is a fork of CometBFT v0.38.17. It is used as the consensus engine for the loca blockchain. The module path is kept as github.com/cometbft/cometbft — import via a replace directive in your go.mod:

github.com/cometbft/cometbft v0.38.17 => github.com/localitynetwork/locabft v0.38.17-loca.0

Changes vs upstream CometBFT v0.38.17

Problem: infinite empty-block loop on Cosmos SDK chains

The upstream needProofBlock() function returns true whenever the previous block's AppHash differs from the header. On Cosmos SDK chains, the BeginBlocker modules (mint, distribution, slashing, staking) modify the AppHash on every block — including empty ones. With create_empty_blocks = false, this caused CometBFT to produce empty blocks in an infinite loop, ignoring the configuration entirely.

Fix: needCommitBlock in consensus/state.go

Replaces needProofBlock with a simpler function that only forces a block in three cases:

1. Genesis height — so the initial AppHash is recorded in a block header.
2. After restart — one empty "warm-up" block forces FinalizeBlock, refreshing Cosmos SDK module state (mint, staking, distribution) before user transactions arrive. Without this, txs submitted right after a node restart may be rejected against stale state.
3. After a block with transactions — one empty "commit" block records the resulting AppHash in the next header. Because this block has NumTxs==0, the rule does not apply to the block after it, breaking the loop automatically.

After case 3, the node waits for new transactions (or the keepalive interval expires).

Keepalive (create_empty_blocks_interval)

When create_empty_blocks = false and create_empty_blocks_interval is set (e.g. "1h"), a timeout is scheduled each time the node enters wait mode. When it fires, one empty block is produced to keep the chain alive and prevent validator downtime penalties. The node then returns to wait mode and schedules the next keepalive.

Modified files

File	Change
consensus/state.go	Replace needProofBlock with needCommitBlock; add startupBlockCommitted warm-up field; add [locabft] log messages

All fork-specific code is tagged with locabft: in comments and [locabft] in log messages, making it easy to identify changes with grep and to filter logs on validators:

docker logs val-hana 2>&1 | grep "\[locabft\]"

Log message	Meaning
[locabft] startup block: warming ABCI app state	First block after restart (warm-up)
[locabft] startup block: ABCI app state ready	ABCI app state refreshed
[locabft] waiting for txs	Node idle, waiting for transactions
[locabft] txs available, proposing block	New txs in mempool
[locabft] commit block: recording AppHash after txs	Empty block to record AppHash
[locabft] keepalive: interval elapsed, proposing empty block	Periodic keepalive block

Using this fork in your project

go.mod replace directive

replace (
    github.com/cometbft/cometbft v0.38.17 => github.com/localitynetwork/locabft v0.38.17-loca.0
)

No imports need to change — all github.com/cometbft/cometbft/... paths resolve automatically via the replace directive.

GONOSUMDB

Go verifies module hashes against the public transparency log at sum.golang.org. Because localitynetwork/locabft may not be indexed there yet, builds on a fresh machine can fail with:

verifying github.com/localitynetwork/locabft@v0.38.17-loca.0:
  checksum mismatch or not found in sum database

This is not a security risk — the go.sum file in your project already contains the correct hashes and protects against tampering. To skip the external lookup, set:

go env -w GONOSUMDB=github.com/localitynetwork/*

Or per-command:

GONOSUMDB=github.com/localitynetwork/* go install ./...

---

CometBFT

Byzantine-Fault Tolerant State Machine Replication. Or Blockchain, for short.

Branch	Tests	Linting
main
v0.38.x
v0.37.x
v0.34.x

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine - written in any programming language - and securely replicates it on many machines.

It is a fork of Tendermint Core and implements the Tendermint consensus algorithm.

For protocol details, refer to the CometBFT Specification.

For detailed analysis of the consensus protocol, including safety and liveness proofs, read our paper, "The latest gossip on BFT consensus".

Documentation

Complete documentation can be found on the website.

Releases

Please do not depend on main as your production branch. Use releases instead.

If you intend to run CometBFT in production, we're happy to help. To contact us, in order of preference:

• Create a new discussion on GitHub
• Reach out to us via Telegram
• Join the Cosmos Network Discord and discuss in #cometbft

More on how releases are conducted can be found here.

Security

To report a security vulnerability, see our bug bounty program. For examples of the kinds of bugs we're looking for, see our security policy.

Minimum requirements

CometBFT version	Requirement	Notes
main	Go version	Go 1.22 or higher
v0.38.x	Go version	Go 1.22 or higher
v0.37.x	Go version	Go 1.22 or higher
v0.34.x	Go version	Go 1.12 or higher

Install

See the install guide.

Quick Start

• Single node
• Local cluster using docker-compose

Contributing

Please abide by the Code of Conduct in all interactions.

Before contributing to the project, please take a look at the contributing guidelines and the style guide. You may also find it helpful to read the specifications, and familiarize yourself with our Architectural Decision Records (ADRs) and Request For Comments (RFCs).

Versioning

Semantic Versioning

CometBFT uses Semantic Versioning to determine when and how the version changes. According to SemVer, anything in the public API can change at any time before version 1.0.0

To provide some stability to users of 0.X.X versions of CometBFT, the MINOR version is used to signal breaking changes across CometBFT's API. This API includes all publicly exposed types, functions, and methods in non-internal Go packages as well as the types and methods accessible via the CometBFT RPC interface.

Breaking changes to these public APIs will be documented in the CHANGELOG.

Upgrades

In an effort to avoid accumulating technical debt prior to 1.0.0, we do not guarantee that breaking changes (i.e. bumps in the MINOR version) will work with existing CometBFT blockchains. In these cases you will have to start a new blockchain, or write something custom to get the old data into the new chain. However, any bump in the PATCH version should be compatible with existing blockchain histories.

For more information on upgrading, see UPGRADING.md.

Supported Versions

Because we are a small core team, we have limited capacity to ship patch updates, including security updates. Consequently, we strongly recommend keeping CometBFT up-to-date. Upgrading instructions can be found in UPGRADING.md.

Currently supported versions include:

• v0.38.x: CometBFT v0.38 introduces ABCI 2.0, which implements the entirety of ABCI++
• v0.37.x: CometBFT v0.37 introduces ABCI 1.0, which is the first major step towards the full ABCI++ implementation in ABCI 2.0
• v0.34.x: The CometBFT v0.34 series is compatible with the Tendermint Core v0.34 series

Resources

Libraries

• Cosmos SDK; A framework for building applications in Golang
• Tendermint in Rust
• ABCI Tower

Applications

• Cosmos Hub
• Terra
• Celestia
• Anoma
• Vocdoni

Research

Below are links to the original Tendermint consensus algorithm and relevant whitepapers which CometBFT will continue to build on.

• The latest gossip on BFT consensus
• Master's Thesis on Tendermint
• Original Whitepaper: "Tendermint: Consensus Without Mining"

Join us

CometBFT is currently maintained by Informal Systems. If you'd like to work full-time on CometBFT, we're hiring!

Funding for CometBFT development comes primarily from the Interchain Foundation, a Swiss non-profit. Informal Systems also maintains cometbft.com.