Skip to main content
Cosmos SDK v0.54 is the largest performance-focused release in the project’s history. It ships a suite of opt-in experimental optimizations (parallel transaction execution, application-managed mempools, and a new P2P networking layer) alongside a full OpenTelemetry observability stack, BLS 12-381 signature support, and a new Proof of Authority module.
Before upgrading, read the v0.54 Upgrade Guide for breaking changes and migration instructions.

​
Proof of Authority Module

The Proof of Authority (PoA) module is now available as part of the Cosmos Enterprise offering. PoA lets chains define and manage their validator set by authority rather than by stake, making it well-suited for private networks, consortium chains, and permissioned deployments that need direct control over who participates in consensus. Unlike traditional proof-of-stake, validator membership is not determined by token staking. Validators are explicitly authorized, updated, and removed through on-chain administrative actions. The module also supports token-free operation, letting chains launch and run without issuing a native token, with a clear path to transition to proof-of-stake if needed. The module ships as a production-ready component under Cosmos Enterprise. See the PoA module documentation in the Cosmos Enterprise documentation to learn how to integrate it into your application.

​
Experimental Performance Optimizations

Block-STM, Krakatoa Mempool, and libp2p are experimental, opt-in optimizations. They are not enabled by default and should be tested thoroughly before being used on a production chain.

​
Block-STM: Parallel Transaction Execution

Block-STM brings deterministic parallel transaction execution to Cosmos SDK via optimistic concurrency control. Rather than processing transactions serially, Block-STM executes them concurrently across multiple workers, detects read/write conflicts, and re-executes only the conflicting transactions. The resulting AppHash is identical to serial execution. Block-STM is integrated directly into the FinalizeBlock phase of BaseApp. When enabled, it can significantly increase block processing throughput on multi-core hardware. The number of parallel workers is configurable and scales with available CPU cores. Key properties:
  • Produces identical results to serial execution, deterministic and safe
  • Uses optimistic concurrency control with read/write set tracking on the IAVL storage layer
  • Conflict detection and re-execution are handled automatically
  • Requires disabling the block gas meter (safe when ProcessProposal validates total gas)
To enable Block-STM, wire in the STMRunner and set the bank module as the first EndBlocker. See the Block-STM documentation for full wiring instructions.

​
Krakatoa: Application-Side Mempool

The Krakatoa mempool is a new architecture that delegates transaction storage, validation, and rechecking entirely to the application. The core benefit is faster block times: by removing ABCI lock contention between mempool operations and consensus, PrepareProposal and FinalizeBlock no longer stall waiting for CheckTx or recheck passes to complete. It spans all three layers of the stack: CometBFT introduces a new app mempool type that replaces the traditional flood mempool. Instead of holding the ABCI lock for CheckTx and recheck operations, CometBFT forwards transactions to the application via two new ABCI methods (InsertTx and ReapTxs) and never holds the ABCI lock for mempool work. This means high transaction volume no longer delays block building or finalization. See the CometBFT Krakatoa documentation for details. Cosmos EVM implements the full Krakatoa specification in ExperimentalEVMMempool. It manages two sub-pools (an EVM LegacyPool and a Cosmos RecheckMempool) with fully async insertion via background queues, application-side rechecking, and a non-blocking HeightSync store that lets proposers collect rechecked transactions without waiting for a full recheck pass to complete. This keeps proposals fast even when recheck is still in progress. See the Cosmos EVM Krakatoa documentation for details. Benefits:
  • Faster block times by removing ABCI lock contention between mempool and consensus
  • The application owns full control over transaction prioritization, ordering, and block building
  • Application-driven rechecking with cancellation support on new block arrival
  • Proposers can build blocks from partial recheck results when block time is tight
To enable these optimizations, see the Krakatoa documentation and Cosmos EVM Krakatoa documentation.

​
libp2p: Next-Generation P2P Networking

CometBFT’s libp2p integration replaces the legacy comet-p2p networking layer with go-libp2p, a production-proven peer-to-peer stack used across the broader blockchain ecosystem. The existing CometBFT actor model (Switch, Peer, Reactor, envelopes) remains unchanged; libp2p replaces only the transport layer beneath those abstractions. The key improvements are:
  • QUIC transport instead of TCP, with native stream-oriented message passing and concurrent receive pipelines
  • Autoscaled worker pools per reactor, dynamically adjusting between 4-32 workers (8-512 for the mempool reactor) based on throughput, queue pressure, and latency percentiles
  • Combined mode (blocksync.combined_mode = true) lets slower nodes ingest verified blocks via blocksync while consensus is running simultaneously, improving network liveness
  • In internal benchmarks, libp2p has been a key enabler of over 2,000 TPS throughput results across the stack
To enable these optimizations, see the libp2p documentation.

​
Observability: OpenTelemetry

​
Telemetry

The telemetry package has been fully rearchitected around OpenTelemetry. The legacy github.com/hashicorp/go-metrics integration is deprecated, replaced by a unified initialization path for traces, metrics, and logs via the OpenTelemetry declarative configuration spec. What’s new:
  • Drop an otel.yaml in your node’s config directory (or set OTEL_EXPERIMENTAL_CONFIG_FILE) to enable full observability with zero code changes
  • Built-in instrumentation for host metrics (CPU, memory, network), Go runtime (goroutines, GC), and disk I/O
  • A bridge sink (metrics-sink = "otel") allows existing go-metrics calls to flow into the OpenTelemetry meter provider without code changes
  • BaseApp is now instrumented with OpenTelemetry traces out of the box
See the Telemetry documentation for setup instructions and configuration options.

​
Log v2

The cosmossdk.io/log package is updated to v2, adding context-aware logger methods (InfoContext, WarnContext, ErrorContext, DebugContext). These methods extract the active OpenTelemetry trace context from the sdk.Context, allowing logs to be correlated with distributed traces in tools like Grafana Tempo and Loki. If your OpenTelemetry configuration includes a logger provider, the SDK automatically provisions a MultiLogger that writes to both stdout and the configured provider via otelslog. See the Log v2 documentation for setup and usage examples.

​
Other Highlights

Below are some of the other major highlights of this release. For a full list of changes, see the Release Notes.

​
BLS 12-381 Signature Support

Cosmos SDK v0.54 enables full BLS 12-381 signature support (#25471, #24872). BLS signatures are significantly more compact than ed25519 and support efficient signature aggregation, which is foundational for scaling validator sets and threshold signing schemes. CLI commands (init, gentx, collect-gentx) now support BLS key generation.

​
Store v2

The store package moves to cosmossdk.io/store/v2, a required upgrade for all v0.54 applications. Store v2 is the foundation for both Block-STM parallel execution and the upcoming IAVLX storage engine.

​
Module Deprecations and Moves

The following modules are no longer actively maintained by Cosmos Labs and have been moved to ./contrib:
  • x/circuit → contrib/x/circuit
  • x/nft → contrib/x/nft
  • x/crisis → contrib/x/crisis
The x/group module moves to the Cosmos Enterprise offering and continues to be maintained there.

​
Decoupled Governance

x/gov is decoupled from x/staking. The keeper.NewKeeper constructor now requires a CalculateVoteResultsAndVotingPowerFn parameter, enabling governance to work with alternative validator power sources without depending on the staking module directly.

​
Multi-Version Historical gRPC

gRPC query clients can now serve multiple historical SDK binaries simultaneously (#25565). This allows nodes to respond to queries against older chain state using the correct binary for that height, which is particularly useful for archive nodes and tooling that needs to query state across upgrade boundaries.

​
Changelog

For the full list of changes, bug fixes, and breaking changes, see the Release Notes.

​
Upgrade Guide

For detailed instructions on how to upgrade your application to v0.54, see the Upgrade Guide.