How Akash Integrates with CometBFT for Consensus and Finality

Akash integrates with CometBFT through the ABCI (Application-Blockchain Interface) to inherit deterministic finality, where transactions become irreversible immediately after block commitment once two-thirds of validators sign.

The Akash Network delegates its consensus layer entirely to CometBFT (formerly Tendermint), leveraging the Cosmos SDK's BaseApp to handle ABCI lifecycle callbacks. This architecture allows the decentralized cloud marketplace to benefit from Byzantine Fault Tolerant (BFT) finality while maintaining application-specific logic for deployments, leases, and marketplace operations.

ABCI Hook Registration in app/app.go

The integration begins in app/app.go, where the Akash application initializes a Cosmos SDK BaseApp and registers ABCI callbacks that CometBFT invokes during block processing. The NewApp constructor wires these hooks to delegate consensus events to the application's module manager.

// app/app.go – NewApp constructor
bapp := baseapp.NewBaseApp(AppName, logger, db, txConfig.TxDecoder(), options...)
// ...
// Register ABCI callbacks for CometBFT consensus lifecycle
app.SetInitChainer(app.InitChainer)          // InitChain
app.SetPreBlocker(app.PreBlocker)            // Pre‑block (FinalizeBlock)
app.SetBeginBlocker(app.BeginBlocker)        // BeginBlock
app.SetEndBlocker(app.EndBlocker)            // EndBlock
app.SetProcessProposal(baseapp.NoOpProcessProposal()) // ProcessProposal (accept all)

The BeginBlocker implementation demonstrates this delegation pattern, forwarding execution to the module manager's BeginBlock method:

func (app *AkashApp) BeginBlocker(ctx sdk.Context) (sdk.BeginBlock, error) {
    return app.MM.BeginBlock(ctx)
}

Source: [app/app.go](https://github.com/akash-network/node/blob/main/app/app.go)

CometBFT Type Imports and Dependencies

Akash imports core CometBFT libraries directly to interact with low-level ABCI types and consensus structures. These imports appear throughout the codebase, particularly in app/app.go and server utilities.

import (
    abci "github.com/cometbft/cometbft/abci/types"
    tmjson "github.com/cometbft/cometbft/libs/json"
    cmos  "github.com/cometbft/cometbft/libs/os"
    tmproto "github.com/cometbft/cometbft/proto/tendermint/types"
    tmtypes "github.com/cometbft/cometbft/types"
)

Additional integration points include util/server/server.go for node startup and cmd/akash/cmd/testnetify/cmt_abci.go for testnet ABCI wrappers.

Consensus Flow and Finality Guarantees

The Akash-CometBFT integration follows a deterministic block lifecycle that ensures immediate finality upon commitment. The consensus engine handles validator coordination while the application manages state transitions.

Consensus Step	CometBFT Engine	Akash Application Layer
InitChain	Loads genesis, initializes validator set	InitChainer unmarshals genesis state and initializes modules
FinalizeBlock	Proposes block, runs pre-block logic	PreBlocker executes pre-block logic (e.g., infinite gas meter)
BeginBlock	Locks block, tallies votes	BeginBlocker triggers module BeginBlock hooks
DeliverTx	Executes transactions sequentially	Routes transactions, processes fees, updates state
EndBlock	Determines validator set changes	EndBlocker runs module EndBlock hooks
Commit	Finalizes block with >2/3 validator signatures	Persists multi-store state root; guarantees irreversibility

Once CometBFT reaches the Commit phase with greater than two-thirds validator signatures, the block achieves deterministic finality. Akash persists its multi-store state only at this commit point, ensuring that no forks can occur after finalization unless more than one-third of validators collude to double-sign (which would trigger slashing).

Design Trade-offs: The No-Op ProcessProposal

Akash deliberately configures ProcessProposal as a no-op that accepts all proposals using baseapp.NoOpProcessProposal(). This design choice prioritizes liveness during network upgrades by avoiding mismatched PrepareProposal and ProcessProposal logic that could stall the chain.

This configuration does not weaken finality—the consensus engine still requires the standard >2/3 validator agreement before committing any block. However, it shifts transaction validation to the DeliverTx phase, meaning malformed or malicious transactions are processed and their failures recorded in transaction results, but the containing block remains final. This represents a conscious trade-off: consensus safety is preserved, while application-level validation occurs during execution rather than proposal acceptance.

Practical Implications for Developers

When building on Akash, understanding this finality model affects how you interact with the network and design cross-chain applications:

• Transaction Confirmation: A transaction is final once the RPC reports its block height as committed. No additional confirmations are required beyond the single block commitment.
• State Sync Reliability: Developers can rely on CometBFT's guarantees for bridges and state-sync operations, as the underlying consensus prevents forks after commit.
• Upgrade Coordination: Configuration changes must respect height-based checkpoints since consensus guarantees immutability of committed history.
• Client Integration: Standard Cosmos SDK client code submits transactions that become final immediately upon inclusion in a committed block.

// Client-side transaction submission example
cliCtx, err := client.GetClientTxContext(cmd)
if err != nil { return err }

msg := markettypes.NewMsgCreateLease(...)
if err := msg.ValidateBasic(); err != nil { return err }

txFactory := tx.Factory{}.
    WithChainID(chainID).
    WithTxConfig(app.TxConfig).
    WithGasAdjustment(1.2)

txBuilder := txFactory.NewTxBuilder()
if err := txBuilder.SetMsgs(msg); err != nil { return err }

txBytes, err := tx.Sign(txFactory, cliCtx.GetFromName(), txBuilder, true)
if err != nil { return err }

res, err := cliCtx.BroadcastTx(txBytes)
// res.Height contains the committed block height → transaction is final

Summary

• Akash integrates with CometBFT through the ABCI interface implemented via Cosmos SDK's BaseApp in app/app.go.
• Deterministic finality is achieved immediately upon block commitment when >2/3 of validators sign, with no possibility of reversion without slashing conditions.
• The no-op ProcessProposal design ensures chain liveness during upgrades by accepting all proposals, deferring transaction validation to DeliverTx.
• State changes persist only at the Commit phase, making transactions irreversible once included in a committed block.
• Developers can rely on single-block finality for deployment transactions, lease agreements, and cross-chain operations.

Frequently Asked Questions

What is the ABCI and how does Akash use it?

The Application-Blockchain Interface (ABCI) is the boundary between CometBFT's consensus engine and the application logic. Akash implements ABCI by registering callbacks (InitChainer, BeginBlocker, EndBlocker, etc.) with a Cosmos SDK BaseApp in app/app.go. This allows CometBFT to drive the block lifecycle while Akash handles the specific state transitions for its cloud computing marketplace.

How does Akash ensure transaction finality?

Akash inherits immediate finality from CometBFT's Byzantine Fault Tolerant consensus. Once a block receives signatures from more than two-thirds of the validator set and reaches the Commit phase, it becomes irreversible. The application state is only persisted at this commit point, guaranteeing that transactions cannot be reverted or forked without a supermajority attack that would slash validators.

Why does Akash accept all block proposals without validation?

Akash uses baseapp.NoOpProcessProposal() to accept all proposals during the ProcessProposal ABCI phase. This liveness optimization prevents network stalls during software upgrades where validator nodes might run slightly different application versions. Finality remains secure because CometBFT still requires >2/3 validator agreement to commit the block; invalid transactions are simply rejected during DeliverTx with their failure recorded on-chain.

What happens if a transaction fails during DeliverTx?

If a transaction fails validation or execution during the DeliverTx phase, CometBFT still includes it in the final block, but marks the transaction result as failed and applies no state changes for that specific transaction. The block itself remains final and immutable. This design separates consensus finality from application-level transaction success, ensuring that consensus progress continues regardless of individual transaction outcomes.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}