CometBFT ABCI 2.0 (ADR-060, ADR-101)

ABCI 2.0, defined across ADR-060 and ADR-101, is the most significant architectural change to the Application Blockchain Interface since the inception of the Cosmos SDK. It replaces the single, linear DeliverTx flow with a two-phase block construction process: PrepareProposal and ProcessProposal. This redesign moves the Cosmos stack from a model where the consensus engine dictates a block to the application, to one where the application actively builds and validates the block. For appchain developers, this is the new standard for customizing mempool logic, implementing application-specific MEV strategies, and enforcing deterministic transaction ordering.

The PrepareProposal phase allows the application to construct an ordered list of transactions from its local mempool, replacing the consensus engine's default block building. This is where an appchain can implement priority ordering, inject oracle price updates, or censor transactions according to its own rules. The subsequent ProcessProposal phase requires the application to deterministically validate the block proposed by a validator. If the application rejects the proposal, consensus will move to the next round, making this a critical security boundary. A non-deterministic or buggy ProcessProposal implementation can cause a chain halt, as different validators may disagree on a block's validity.

The operational impact is substantial. Validator operators must now manage and monitor application-side logic that directly influences consensus liveness. A misconfiguration in a custom PrepareProposal handler can lead to a validator building empty or invalid blocks, while a bug in ProcessProposal can cause a node to fall out of consensus. For teams building on the Cosmos SDK, migrating to ABCI 2.0 is not optional for new chains and requires a careful rewrite of mempool and block acceptance logic. Chainscore Labs can review custom PrepareProposal and ProcessProposal implementations to ensure they are deterministic, secure against MEV manipulation, and will not cause liveness failures under edge-case transaction loads.

The PrepareProposal and ProcessProposal methods, introduced by ADR-060 and refined by ADR-101, represent a fundamental shift in the Application Blockchain Interface (ABCI) for CometBFT. They replace the legacy BeginBlock-DeliverTx-EndBlock flow with a model where the application is a first-class participant in consensus. PrepareProposal allows the application to deterministically construct the canonical block from the proposer's mempool, enabling custom ordering, transaction injection, and pre-execution. ProcessProposal then requires every validator to verify that the proposed block is a valid output of the application's PrepareProposal logic, rejecting the block if it deviates.

This flow has profound operational and economic implications for appchain developers and validators. It is the primary interface for implementing application-specific MEV strategies, such as top-of-block arbitrage, batch auctions, or fair ordering protocols. The application's logic in PrepareProposal is not merely a suggestion; it is a consensus-critical function. A non-deterministic or buggy implementation will cause chain halts as validators disagree on the validity of proposed blocks. The ProcessProposal method must be a pure, deterministic function that mirrors the PrepareProposal logic, verifying the block's correctness without re-executing complex state transitions that could introduce non-determinism.

For teams building on the Cosmos SDK, this is the most significant change to the consensus interface since the launch of IBC. Customizing these methods requires deep integration with the SDK's PrepareProposalHandler and ProcessProposalHandler. A review must ensure that the application's block construction logic is deterministic, its verification logic is efficient, and that no state mutations occur during ProcessProposal that could cause a fork. Chainscore Labs can perform a targeted review of a custom ABCI 2.0 implementation to verify correctness, assess performance under load, and ensure that the handler logic does not introduce liveness or safety risks to the chain.