Somewhere beneath the surface of over a hundred blockchain networks, from Cosmos Hub to Osmosis to Celestia, there's a consensus engine quietly doing the heavy lifting. It's called CometBFT, and unless you've spent time wandering the Cosmos ecosystem, you've probably never encountered it. 

That's about to change. Projects outside of Cosmos are starting to adopt it, and we're one of them: Reactive Network is swapping out its entire Ethereum-style consensus stack in favor of CometBFT. 

So what is this thing, why does it exist, and what makes it different from the consensus approach Ethereum uses? Let's take a walk through it.

What a Consensus Engine Actually Does

Before we get into mechanics, it helps to be clear about what we're even talking about. A consensus engine is the part of a blockchain that gets all the nodes (independently operated computers scattered around the world) to agree on what has happened and in what order. Which transactions are valid? What's the next block? Who gets to propose it?

Every blockchain needs answers to these questions, and the consensus engine is the system that produces them. Think of it as the parliamentary procedure of a decentralized network: not the legislation itself, but the rules for how votes happen and how decisions become official.

What makes consensus design interesting is that the participants don't trust each other. Some might be offline. Some might be actively trying to cheat. The engine has to produce reliable agreement anyway.

Tendermint Legacy

CometBFT is the direct descendant of Tendermint Core, a consensus algorithm that Jae Kwon began designing in 2014, before Ethereum even launched. The idea was to take decades of academic research on Byzantine fault tolerance (BFT) and turn it into a practical blockchain consensus protocol. "Byzantine fault" sounds intimidating, but the concept is simple: a participant that doesn't just crash, but actively misbehaves, sending contradictory messages, proposing invalid data, or trying to manipulate the outcome. CometBFT keeps the network safe as long as fewer than one-third of validators are acting this way.

In 2023, the project was forked from Tendermint Core and relaunched as CometBFT, maintained by Informal Systems. Along with the rename came meaningful protocol upgrades, including ABCI++ (more on this shortly) and improved developer tooling.

Reaching Agreement

Here's where it gets fun. CometBFT's consensus process for each new block follows a structured round with three phases: Propose, Prevote, and Precommit. The diagram above shows the flow, but a few details are worth mentioning.

The proposer for each round isn't random. It's selected through a deterministic rotation weighted by stake, so the network always knows whose turn it is. If a validator receives a block it considers invalid, or never receives one at all (maybe the proposer went offline), it can prevote "nil", signaling there's nothing worth committing this round. The protocol also includes a locking mechanism that prevents validators from flip-flopping between conflicting blocks across rounds, which is essential for blocking a subtle class of double-spend attacks.

The entire process typically completes in a matter of seconds. For our implementation, the target is roughly one-second block times.

Ethereum's Approach

To appreciate what CometBFT does differently, it helps to understand how Ethereum handles the same problem. Ethereum's post-Merge consensus protocol is called Gasper, a combination of two components: LMD-GHOST (a fork-choice rule that picks which chain tip to build on) and Casper FFG (a finality gadget that periodically locks in history as irreversible).

As the diagram shows, the structure revolves around slots and epochs. A block that appears in its slot is not final. It has probabilistic confirmation (more attestations make it more likely to stick), but true finality doesn't arrive until two full epochs have passed. That's roughly 12.8 minutes. During that window, chain reorganizations are possible: a block you thought was confirmed can get replaced by a competing fork.

For most everyday Ethereum usage, like sending tokens or interacting with a DeFi protocol, this delay is tolerable. Users typically treat a few confirmations as "good enough". But for certain use cases, probabilistic finality is structurally inadequate.

Reorg Problem in Cross-Chain Systems

This is where our own transition makes for a useful illustration. Reactive Network is built around reactive contracts, which are smart contracts that listen to events on other EVM chains (Ethereum, Base, Arbitrum, and so on) and automatically execute logic in response. Think of it as an automation layer: when something happens on chain A, a reactive contract can trigger an action on chain B. The diagram below shows what can go wrong under probabilistic finality, and how CometBFT changes the picture.

Under CometBFT, our blocks achieve instant finality. Once validated, a block can't be reorganized. The origin chains we listen to still have their own finality characteristics, but our layer no longer introduces additional uncertainty.

We describe this as the distinction between reactive finality, which CometBFT provides on our chain, and origin finality, which depends on whichever chain we're monitoring. The former is now deterministic. The latter remains whatever the origin chain provides.

ABCI

CometBFT separates the consensus engine from the application logic entirely. The consensus engine handles networking, peer discovery, block propagation, and the voting protocol. The application, whatever you want the blockchain to actually do, communicates with it through a clean, standardized interface called ABCI (Application Blockchain Interface). Teams can build their application in whatever language and framework suits them and just plug it into CometBFT for consensus, without thinking about peer-to-peer networking or vote counting.

This is the approach that allowed CometBFT to run under an incredibly diverse set of chains in the Cosmos ecosystem. For us, it's especially useful because ABCI's hook-based design lets us implement our event-listening primitives directly at the consensus layer, rather than bolting them onto infrastructure that wasn't designed for that purpose.

Instant Finality Isn't Free

Every consensus design involves trade-offs, and CometBFT is no exception as its finality guarantee depends on a known, relatively compact validator set. Every validator participates in every round of voting, which is what makes single-block finality possible. That model works well with dozens or even a few hundred validators.

Ethereum takes a different path: its Beacon Chain supports over a million validators, trading finality speed for a much broader participation base. CometBFT-based chains typically operate with 50 to 175 active validators.

The two approaches also handle network stress differently. In CometBFT, the chain prioritizes correctness: if participation drops below the required threshold, block production pauses until enough validators return. Ethereum's fork-choice rule keeps producing blocks under heavier participation drops, though those blocks won't be finalized until conditions stabilize.

These are genuinely different design priorities. Ethereum optimizes for large-scale decentralization and censorship resistance. CometBFT-based chains optimize for performance, finality speed, and architectural flexibility. Neither is universally better. They're built for different contexts, and choosing between them depends on what the application needs most.

Cosmos Ecosystem

CometBFT is the foundation of the Cosmos vision, sometimes called the "Internet of Blockchains": many specialized chains, each running its own instance of CometBFT with its own validator set and application rules, communicating through a shared protocol called IBC (Inter-Blockchain Communication). The result is a network of networks, each sovereign but interoperable.

Our adoption of CometBFT, while maintaining full EVM compatibility, is something of a hybrid. We take the developer experience and tooling of Ethereum (Solidity, Hardhat, Foundry, Remix) and pair it with the consensus performance of Cosmos. You write the same smart contracts you'd write for any EVM chain, but the engine underneath is playing by different rules.

Going Forward

The trend is worth watching. Ethereum itself has been actively researching "single-slot finality", an approach that would make its consensus behave more like CometBFT's, finalizing blocks within a single slot rather than waiting two epochs. It's one of those moments where two different design philosophies are converging toward similar conclusions from different starting points.

At Reactive Network, we're already there. Our Omni fork transition replaces the old Geth+Prysm stack with CometBFT while preserving all existing state, balances, and contracts. Lasna Testnet running the new architecture is live and open to the public, being put through its paces by both our team and the community. Mainnet follows, and we'll have more to share on that timeline soon.

Consensus design has historically been one of those topics that feels deeply esoteric until it suddenly isn't. The moment your cross-chain transaction gets caught in a reorg, or your callback fires based on an event that no longer exists, or you're waiting 13 minutes to know if your transaction is truly irreversible, that's when the consensus layer stops being an abstraction and starts being the thing that determines whether your system works or doesn't.

CometBFT is one answer to those problems. It's battle-tested across hundreds of chains, it's architecturally elegant in ways that reward curiosity, and it's increasingly showing up in places you wouldn't have expected it a few years ago. If you're interested in how blockchains actually work under the hood, not just what you can build on them, but how they reach agreement about reality, it's well worth your time to dig in.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. It runs on CometBFT consensus, providing instant finality and roughly 1-second block times while maintaining full EVM compatibility.

Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, deciding autonomously when to send cross-chain callback transactions. This model supports conditional cross-chain state changes and continuous cross-chain workflows.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!