v0.53.x to v0.54.x of Cosmos SDK.
However, this guide is not exhaustive for all breaking changes. For a comprehensive list of all breaking changes in v0.54.0, see the Changelog.
Always read the App Wiring Changes section for more information on application wiring updates.
Table of Contents
- Upgrade Checklist
- Required Changes
- Conditional Changes
- New Features and Non-Breaking Changes
- Upgrade Handler
- IBC v11 Updates
- Cosmos Performance Upgrades (Experimental)
Upgrade Checklist
Use this checklist first, then read the linked sections for the exact code or wiring changes.- Update
x/govkeeper wiring, as thex/govmodule has been decoupled fromx/staking. See Keeper Initialization. - Update your governance hooks if you implement
AfterProposalSubmission. See GovHooks Interface. - Update
x/epochs.NewAppModuleif your app includesx/epochs. See x/epochs. - Put
x/bankfirst inSetOrderEndBlockers. See x/bank. - Update your node service registration if your app exposes
NodeService. See NodeService. - Migrate imports for removed
x/Go modules. See Removed Go Modules. - Update required Cosmos SDK Go module dependencies. See Module Version Updates.
- Migrate to
contrib/imports if you usex/circuit,x/nft, orx/crisis. See Module Deprecations. - Migrate to Cosmos Enterprise if you use the
x/groupmodule. See Groups Module. - Update imports to
cosmossdk.io/log/v2if your app imports the log package directly. See Log v2. - Migrate imports to
github.com/cosmos/cosmos-sdk/store/v2. See Store v2. - Migrate any remaining
BaseApp.NewUncachedContext()usage. See Store v2. - If using
systemtestsupdate import togithub.com/cosmos/cosmos-sdk/tools/systemtests. See Renamed Go Modules. - Review IBC v11 Updates if your chain uses IBC. Several APIs have been removed.
- Review Centralized Authority via Consensus Params. No upgrade action is required to keep using per-keeper authorities.
- Review Telemetry. No upgrade action is required to keep existing telemetry wiring, but upgrading to OpenTelemetry is strongly encouraged.
- Review PoA Module if you are interested in adopting the new Cosmos Enterprise Proof of Authority module.
- Review Cosmos Performance Upgrades (Experimental) if you are interested in experimenting with BlockSTM, LibP2P, or AdaptiveSync.
Required Changes
All chains upgrading tov0.54.x should review and apply the changes in this section.
This guide provides an overview of the major changes in v0.54.0. However, this guide is not exhaustive for all breaking changes. For a comprehensive list of all breaking changes in v0.54.0, see the Changelog.
App Wiring Changes
x/gov
Keeper Initialization
Thex/gov module has been decoupled from x/staking. The keeper.NewKeeper constructor now requires a CalculateVoteResultsAndVotingPowerFn parameter instead of a StakingKeeper.
Before:
CalculateVoteResultsAndVotingPowerFn. If not provided, it will use the StakingKeeper (also optional) to create the default function.
GovHooks Interface
TheAfterProposalSubmission hook now includes the proposer address as a parameter.
Before:
x/epochs
The epochs module’sNewAppModule function now requires the epoch keeper by pointer instead of value, fixing a bug related to setting hooks via depinject.
x/bank
The bank module now contains anEndBlock method to support the new BlockSTM experimental package. BlockSTM requires coordinating object store access across parallel execution workers, and x/bank’s EndBlock handles the finalization step for that. All applications must make this change, whether or not they enable BlockSTM, because the EndBlock registration is now part of the module’s standard lifecycle.
NodeService
The node service has been updated to return the node’s earliest store height in theStatus query. Please update your registration with the following code (make sure you are already updated to github.com/cosmos/cosmos-sdk/store/v2):
Removed Go Modules
Mostcosmossdk.io vanity URLs for modules under x/ have been removed. These separate Go modules caused dependency version management to be unpredictable; different modules could be pinned to different SDK versions, leading to compatibility issues. Consolidating everything under github.com/cosmos/cosmos-sdk gives developers a single, versioned dependency to manage.
The following must be updated:
cosmossdk.io/x/evidence->github.com/cosmos/cosmos-sdk/x/evidencecosmossdk.io/x/feegrant->github.com/cosmos/cosmos-sdk/x/feegrantcosmossdk.io/x/upgrade->github.com/cosmos/cosmos-sdk/x/upgradecosmossdk.io/x/tx->github.com/cosmos/cosmos-sdk/x/tx
Renamed Go Modules
Thecosmossdk.io/systemtests go module is now named github.com/cosmos/cosmos-sdk/tools/systemtests.
Module Version Updates
cosmossdk.io/client/v2has been updated to v2.11.0
Log v2
The log package has been updated tov2. Applications using v0.54.0+ of Cosmos SDK will be required to update imports to cosmossdk.io/log/v2. Usage of the logger itself does not need to be updated.
The v2 release of log adds contextual methods to the logger interface (InfoContext, DebugContext, etc.), allowing logs to be correlated with OpenTelemetry traces.
To learn more about the new features offered in log/v2, as well as setting up log correlation, see the log package documentation.
Store v2
Store v2 introduces breaking changes. For a comprehensive list of all breaking changes, see the Changelog. The store package has been updated tov2. Applications using v0.54.0+ of
Cosmos SDK will be required to update imports to
github.com/cosmos/cosmos-sdk/store/v2.
BaseApp.NewUncachedContext() was deprecated as part of this work. With store v2, writes must go through a cache/branch first; the SDK no longer exposes a helper that lets applications write directly against the root CommitMultiStore.
If you previously used BaseApp.NewUncachedContext() in tests:
- Replace
app.NewUncachedContext(false, header)withapp.NewNextBlockContext(header)when the test needs a writable context betweenCommit()and the nextFinalizeBlock(). - Replace
app.NewUncachedContext(true, header)withapp.NewContext(true)orapp.NewContextLegacy(true, header)when the test only needs theCheckTxstate.
NewUncachedContext.
Conditional Changes
These changes apply if your chain uses the affected modules, packages, or integrations.Module Deprecations
Cosmos SDK v0.54.0 drops support for the circuit, nft, and crisis modules. Developers can still use these modules, however, they will no longer be actively maintained by Cosmos Labs.x/circuit
The circuit module is no longer being actively maintained by Cosmos Labs and was moved tocontrib/x/circuit.
x/nft
The nft module is no longer being actively maintained by Cosmos Labs and was moved tocontrib/x/nft.
x/crisis
The crisis module is no longer being actively maintained by Cosmos Labs and was moved tocontrib/x/crisis.
Cosmos Enterprise
Cosmos Enterprise is a comprehensive suite of blockchain services and technologies to future-proof your organization’s digital ledger capabilities. It combines hardened protocol modules, infrastructure components, and proactive support and enablement from the engineers building the Cosmos technology stack. Cosmos Enterprise is built for organizations that require reliability, security, and operational confidence as they scale critical blockchain infrastructure in enterprise production environments.Groups Module
The groups module is now maintained under the Cosmos Enterprise offering. If your application usesx/group, you will need to migrate your code to the Enterprise-distributed package and obtain a Cosmos Enterprise license to continue using it. Please see Cosmos Enterprise to learn more.
PoA Module
Cosmos SDK v0.54 includes a Proof of Authority (POA) module under the Cosmos Enterprise offering. Please see Cosmos Enterprise to learn more about using the PoA module in your application.New Features and Non-Breaking Changes
These changes are informational and optional to adopt during the upgrade; they are not required for a successful migration.Telemetry
The telemetry package has been deprecated and users are encouraged to switch to OpenTelemetry.OpenTelemetry
Previously, Cosmos SDK telemetry support was provided bygithub.com/hashicorp/go-metrics which was undermaintained and only supported metrics instrumentation.
OpenTelemetry provides an integrated solution for metrics, traces, and logging which is widely adopted and actively maintained.
The existing wrapper functions in the telemetry package required acquiring mutex locks and map lookups for every metric operation which is suboptimal. OpenTelemetry’s API uses atomic concurrency wherever possible and should introduce less performance overhead during metric collection.
See the telemetry documentation to learn how to set up OpenTelemetry with Cosmos SDK v0.54.0+.
Below is a quick reference on setting up and using meters and traces with OpenTelemetry:
Centralized Authority via Consensus Params
Authority management can now be centralized via thex/consensus module. A new AuthorityParams field in ConsensusParams stores the authority address on-chain. When set, it takes precedence over the per-keeper authority parameter.
This feature introduces no breaking changes: Keeper constructors still accept the authority parameter. It is now used as a fallback when no authority is configured in consensus params. Existing code continues to work without changes.
How AuthorityParams Works
When a module validates authority (e.g., inUpdateParams), it checks consensus params first. If no authority is set there, it falls back to the keeper’s authority field:
AuthorityParams in consensus params via a governance proposal targeting the x/consensus module’s MsgUpdateParams.
Upgrade Handler
This section provides a reference example for implementing the on-chain upgrade itself. The following is an example upgrade handler for upgrading from v0.53.6 to v0.54.0.IBC v11 Updates
IBC v11 introduces several improvements, removes long-deprecated APIs (ParamSubspace from all Keeper constructors, MsgSubmitMisbehaviour, and ibcwasmtypes.Checksums), and adds custom address codec support in the transfer module to enable Cosmos EVM compatibility with IBC transfers.
Read the Changelog and v11 Migration Guide for more information.
Cosmos Performance Upgrades (Experimental)
For Q1 of 2026, Cosmos Labs has been focusing on greatly improving performance of Cosmos SDK applications. v0.54 of Cosmos SDK introduces support for several performance-related features across the stack. The SDK introduces BlockSTM for concurrent transactions, and CometBFT introduces LibP2P andAdaptiveSync.
NOTE: It is important to emphasize that the following are experimental features. We DO NOT recommend running chains with these features enabled in production without extensive testing.
Cosmos SDK
BlockSTM
BlockSTM enables deterministic, concurrent execution of transactions, improving block execution speeds and throughput. Developers interested in experimenting with BlockSTM should read the documentation. Below is an example of setting up BlockSTM:⚠️ Warning: BlockSTM is experimental. Ensure thorough testing before enabling in production.
CometBFT v0.39 Updates
LibP2P
libp2p replaces CometBFT’s legacycomet-p2p transport layer with go-libp2p. It adds native stream-oriented transport, concurrent receive pipelines, and autoscaled worker pools per reactor, reducing queue pressure and improving message flow under load. In benchmarks, libp2p has been a key contributor to reaching over 2000 TPS. Beyond raw throughput, it improves network liveness by making peer communication and block propagation more resilient under sustained congestion and sudden load spikes.
Unlike other opt-in features, to opt-in to libp2p, every validator in the network must upgrade together. CometBFT p2p and libp2p are fundamentally incompatible and cannot interoperate. Because of this, a coordinated network-wide migration at a specific upgrade height is required.
See the libp2p page in the CometBFT documentation for details.
AdaptiveSync
AdaptiveSync allows a node to run blocksync and consensus at the same time for faster recovery behavior. In the default flow, a node starts in blocksync, catches up, then switches to consensus. Under sustained load, a node can remain behind and struggle to catch up. With adaptive_sync enabled, consensus still works normally, but it can also ingest already available blocks from blocksync, allowing nodes to recover more quickly during traffic spikes. AdaptiveSync does not change consensus safety or finality rules.
See the AdaptiveSync documentation for details.