# How Akash Integrates with CometBFT for Consensus and Finality

> Discover how Akash integrates with CometBFT via ABCI to achieve deterministic finality. Learn how transactions become irreversible immediately after block commitment with validator consensus.

- Repository: [Akash Network/node](https://github.com/akash-network/node)
- Tags: deep-dive
- Published: 2026-02-24

---

**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`](https://github.com/akash-network/node/blob/main/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.

```go
// 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:

```go
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)](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`](https://github.com/akash-network/node/blob/main/app/app.go) and server utilities.

```go
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`](https://github.com/akash-network/node/blob/main/util/server/server.go) for node startup and [`cmd/akash/cmd/testnetify/cmt_abci.go`](https://github.com/akash-network/node/blob/main/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.

```go
// 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`](https://github.com/akash-network/node/blob/main/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`](https://github.com/akash-network/node/blob/main/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.