Architecture

An SDK chain is an ABCI application: CometBFT drives it through well-defined lifecycle calls, and the SDK's job is turning those into deterministic state transitions across many modules.

baseapp and the ABCI loop

baseapp implements the ABCI server. For each transaction CometBFT proposes, two paths run: CheckTx (mempool admission — signature, fees, and basic validity) and DeliverTx (actual execution inside a block). baseapp decodes each transaction, runs ante-decorations (fee deduction, signature verification, gas metering setup), then routes every contained message to the module registered for its type.

The module manager

A generated or hand-written module manager holds the chain's module set and sequences their collective behavior: message routing registration, genesis import/export ordering, and the BeginBlock/EndBlock hooks that run around every block. Hook order is explicit and consensus-critical — reordering changes state outcomes.

Stores and commitment

Each module owns one or more scoped stores backed by a shared multistore tree. At every block commit, the multistore produces new Merkle roots; CometBFT hashes the app root into the next block header. This is what makes light clients and IBC verification possible: any claim about app state reduces to a proof against that root.

Gas and panics

All store reads/writes consume gas through wrapping meters — infinite loops in module code cost real fees. Panics in DeliverTx are recovered and surface as failed transactions rather than crashed nodes, preserving liveness at the cost of treating bugs as user-visible failures.