# Tendermint Core: BFT Consensus Middleware for Your Own State Machine

> Tendermint Core replicates a state machine written in any language across machines that may fail or lie. The repository is on an LTS freeze at 0.34.24, so the question is not whether it works but whether you should build on a frozen line.

**tendermint/tendermint** — ⟁ Tendermint Core (BFT Consensus) in Go

- Repository: https://github.com/tendermint/tendermint
- Website: https://tendermint.com/
- Stars: 5,865 · Forks: 2,100
- Language: Go
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tendermint-tendermint

## The problem Tendermint Core solves, and who it is for

Consensus is the part of a distributed system that is hardest to get right and least interesting to the people writing the application. Tendermint Core takes that part and packages it. The README describes it as a Byzantine Fault Tolerant middleware that takes a state transition machine written in any programming language and securely replicates it on many machines. The state machine stays yours. The ordering, the voting rounds, the peer gossip and the block production are the project's.

The audience follows from that split. If you are writing an application where every node must apply the same transactions in the same order, and you do not want to implement leader election and quorum certificates yourself, this is the layer you would otherwise build. The README points at the Cosmos SDK as the Golang application framework, and lists Cosmos Hub, Terra, Celestia, Anoma and Vocdoni as applications. The protocol itself is specified in ./spec/README.md, and the safety and liveness analysis is in the paper "The latest gossip on BFT consensus", linked from the README.

It is not a general-purpose database replication tool. It is not a job queue. The whole design assumes a validator set with stake-like membership and a deterministic application behind an interface.

## How the consensus engine and your application talk to each other

The repository layout shows the split plainly. Top-level directories include consensus/, p2p/, mempool/, blockchain/, evidence/, light/, privval/, rpc/, state/, store/, statesync/ and abci/. The abci/ directory is the boundary: Application BlockChain Interface. Your program implements that interface and Tendermint Core drives it, proposing blocks, collecting votes, committing state, and asking your application to execute the transactions in between.

That boundary is why the README can claim the state machine is written in any programming language. The consensus engine does not read your code. It calls into an interface. Languages other than Go reach it over the wire, which is also why the README links implementations in other ecosystems: tendermint-rs in Rust and tower-abci for the ABCI side.

The rest of the directories map to the mechanics you would expect. mempool/ holds transactions waiting for a block. evidence/ collects proof of misbehaviour by validators. light/ implements light client verification so a client can follow the chain without replaying every block. privval/ isolates validator signing keys, which is a security boundary rather than a convenience. statesync/ lets a node catch up from a snapshot instead of replaying history. None of this is documented in the README beyond the directory names; the README defers to docs.tendermint.com for complete documentation.

## Installing Tendermint Core and running a local cluster

The README states a minimum of Go 1.18 or higher and points at ./docs/introduction/install.md for install instructions. The Makefile builds the binary with the tendermint build tag and writes it to build/tendermint by default, with the version injected through a linker flag:

```bash
make build
```

The OUTPUT variable defaults to build/tendermint, so that is where the binary lands. The Makefile also accepts TENDERMINT_BUILD_OPTIONS, and the sections visible in it handle race, cleveldb, badgerdb, rocksdb and boltdb. Note that cleveldb, rocksdb and race all force CGO_ENABLED=1, while the default is CGO_ENABLED=0. If you pick one of those database backends, you are opting into a cgo build.

For a first real use, the README offers three paths: a single node, a local cluster using docker-compose, and a remote cluster using Terraform and Ansible. The docker-compose.yml in the repository defines four services, node0 through node3, all running the tendermint/localnode image and mounting ./build into /tendermint. Each service sets ID and LOG, and each publishes port 26656 and 26657 on the host, mapped to different host ports per node:

```yaml
services:
  node0:
    image: "tendermint/localnode"
    ports:
      - "26656-26657:26656-26657"
    environment:
      - ID=0
      - LOG=${LOG:-tendermint.log}
    volumes:
      - ./build:/tendermint:Z
```

The container name and the ID environment variable are what distinguish the four nodes; node1 maps 26659-26660, node2 maps 26661-26662, node3 maps 26663-26664. They share a bridge network named localnet on subnet 192.167.10.0/16 with static addresses 192.167.10.2 through 192.167.10.5. What you should see after bringing this up is four nodes reaching consensus on the same chain, which is the point of the exercise: it demonstrates the engine without requiring you to write an application first.

## The LTS freeze is the constraint that matters most

The README opens with an update: TendermintCore featureset is frozen for LTS, pointing at issue 9972. It states that this is the latest stable release used by cosmoshub-4, version 0.34.24, and that the previous main branch, v0.38.xx, can now be found under "main_backup". The release list backs the freeze: 0.34.24 on 2022-11-22, 0.34.23 on 2022-11-09, and 0.37.0-rc2 on 2022-11-29, a release candidate rather than a final release.

Read those two facts together and the practical consequence is blunt. The default branch is main and the repository is not archived, but the README tells you not to depend on main as your production branch and to use releases instead. The line you would ship is a 0.34.x patch. New features are not arriving on it.

The versioning section is the second half of the constraint. Before 1.0.0, anything in the public API can change at any time, and the MINOR version is used to signal breaking changes across the API, including publicly exposed Go types and the RPC interface. The README goes further: breaking changes from a MINOR bump are not guaranteed to work with existing Tendermint blockchains, and in those cases you have to start a new blockchain or write custom code to move old data into the new chain. PATCH bumps are described as compatible with existing blockchain histories. That is the whole upgrade story in one sentence, and it is not a comfortable one for anyone planning a chain that outlives a release cycle.

Support is narrow by design. The README says that because the team is small, patch updates including security updates go only to the most recent minor release and the second-most recent minor release. If you run something older, you are on your own for fixes.

## When Tendermint Core is the wrong tool

The clearest failure case is a new project. If you have not yet written your application and you are choosing a consensus engine, the README's own framing argues against starting here. The featureset is frozen, the branch that would have carried new work is parked under main_backup, and the only non-patch release in the recent list is a release candidate. Building a new chain on a frozen line means accepting that the protocol and API will not move with you.

A second case is a system without a validator set. Tendermint's consensus assumes a known, bounded set of participants whose votes are weighted and whose misbehaviour can be proven and recorded in evidence/. If your problem is ordering events among anonymous or unbounded participants, the BFT model here does not describe it.

A third case is latency-sensitive coordination. BFT consensus with voting rounds is not a low-latency messaging layer, and nothing in the README positions it as one. If two services need to agree on an ordering within single-digit milliseconds, the round structure is overhead you are paying for guarantees you do not need.

Finally, there is the operational surface. Running a validator means running p2p, mempool, privval, state sync and an RPC endpoint, and keeping signing keys isolated. The README does not document rollback or downgrade paths; UPGRADING.md is where upgrade instructions live, and the README is silent on what happens if a minor-version upgrade goes wrong mid-chain.

## CometBFT and the same consensus algorithm in other implementations

The most direct alternative is CometBFT, which comes up in the related searches as "Cometbft vs tendermint". The README does not describe CometBFT's internals or its relationship to this repository, so the honest difference I can state is a boundary, not a feature comparison: the README positions this repository as the LTS-frozen 0.34 line used by cosmoshub-4, and anyone evaluating CometBFT is evaluating a different codebase that this README does not document. If your decision hinges on which of the two is the live line, the README cannot answer it for you.

The alternatives the README does name are implementations of the same protocol in other languages: tendermint-rs in Rust and tower-abci for the ABCI side. Those are not competitors in the usual sense. They are the same consensus algorithm reached through a different runtime, and picking one is a language and ecosystem decision rather than a protocol decision.

For the algorithmic comparison, the searches include "tendermint vs hotstuff". The README does not describe HotStuff, so I will not invent a comparison. What I can say is where to look for the Tendermint side of it: the README links the specification in ./spec/README.md and the paper "The latest gossip on BFT consensus", which is where the protocol's safety and liveness arguments are written down.

## Licence, upgrade cost and what the repository actually commits to

The licence is Apache-2.0, per the repository metadata and the LICENSE file referenced by the README's badge. That is a permissive licence with an explicit patent grant, and it is the same licence family most Go infrastructure projects use. I am not a lawyer and this is not legal advice; if you are redistributing a modified binary or embedding the engine in a product, read LICENSE and the notice obligations yourself. One detail worth noting for anyone building a brand: the README states that the Tendermint trademark is owned by New Tendermint, LLC, and that development was led primarily by All in Bits, Inc. A permissive code licence does not grant trademark rights.

The upgrade cost is where this repository asks the most of you. UPGRADING.md is the documented path, and the versioning section sets the rules: PATCH bumps should be compatible with existing chain history, MINOR bumps may not be, and in the incompatible cases the documented options are to start a new blockchain or write custom migration code. Supported versions are the most recent minor release and the second-most recent, so staying current is not optional if you want security patches. The README's own recommendation is to keep Tendermint up to date, and given the support window that is less advice than arithmetic.

The last push to the repository was on 2026-09-20, so the codebase is being touched. That does not change the README's statement that the featureset is frozen for LTS, and the release list still ends at 0.37.0-rc2 from 2022-11-29. Commits and feature releases are different things.

## Conclusion

Adopt Tendermint Core if you are extending an existing 0.34.x chain such as cosmoshub-4, or if you need a working BFT consensus engine whose message flow is fully specified and whose ABCI boundary keeps your application logic out of the consensus code. Do not adopt it for a new chain: the README states the featureset is frozen for LTS, the previous main branch now lives under main_backup, and the newest release is 0.37.0-rc2 from 2022-11-29. Verify first that the release tag you intend to run is the one your peers run, then read UPGRADING.md and the versioning section before you plan any minor-version move, because a MINOR bump is documented as a breaking change.

## FAQ

### What is Tendermint in blockchain?

Tendermint Core is Byzantine Fault Tolerant middleware that takes a state transition machine written in any programming language and replicates it across many machines. The README describes it as state machine replication, or blockchain for short, and the protocol specification lives in ./spec/README.md.

### How does Tendermint compare with HotStuff?

The README does not describe HotStuff, so this repository cannot make that comparison. For the Tendermint side, the README links the specification in ./spec/README.md and the paper "The latest gossip on BFT consensus", which carries the safety and liveness analysis.

### How is Tendermint different from CometBFT?

The README does not document CometBFT, so it cannot answer this directly. What it does state is that this repository's featureset is frozen for LTS at 0.34.24, the release used by cosmoshub-4, and that the previous main branch now sits under main_backup.

## Sources

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

---

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