2,000+ TPS, Better Stability, and Clearer Upgrades in Cosmos Stack Ledger 2026.1
The newest release of the Cosmos Stack brings together major improvements in performance, load stability, and upgradeability for teams building financial and enterprise applications. Release Family 2026.1 combines core improvements across CometBFT, the Cosmos SDK, and Cosmos EVM into a tested release family designed to be used, upgraded, and supported together.
This release delivers 2,000+ transactions per second sustained with sub-second block times, a more stable transaction path under load, clearer compatibility boundaries across the stack, and new enterprise capabilities for teams that need governance, control, and auditability in production environments.
It includes:
- CometBFT v0.39, with new ABCI changes for application-owned mempools, experimental libp2p networking, and Adaptive Sync
- Cosmos SDK v0.54, with BlockSTM for parallel execution and stronger OpenTelemetry-based observability
- Cosmos EVM v0.7.0, with Krakatoa, our application-owned mempool implementation for the EVM
- Enterprise capabilities, including the new Proof-of-Authority (PoA) Module alongside the Group Module
This release family makes the Stack faster and more stable, and introduces a unified product – the Cosmos Ledger – that is easier for engineers and companies to adopt, operate, and support. This meets the needs of our enterprise users who deploy the Cosmos Ledger to support issuance and settlement as the core DLT system supporting over $75B in tokenized assets.
About the New Release Family Model
The new release family model unites the Cosmos Stack into a cohesive product for teams that want a validated set of core components that can be used, upgraded, and supported together.
To facilitate ease of assembling and validating different combinations of Stack components, we are providing pinned versions, clearer compatibility boundaries, a more predictable upgrade path, and a smaller set of combinations. The resulting Cosmos Ledger is a more unified product and streamlined upgrade experience for teams operating Cosmos DLT technology in high-stakes production environments.
CometBFT v0.39
CometBFT v0.39 introduces three major changes into this release family: new ABCI changes for application-owned mempools, an experimental libp2p networking stack, and Adaptive Sync.
ABCI Changes
The ABCI changes give the application direct control over the mempool lifecycle. In older designs, a significant portion of the mempool lifecycle lived inside CometBFT itself. We’ve made improvements to that design because transaction admission, rechecking, and block-building decisions are all closely tied to application state, so they need to be handled by the application itself.
With new methods like InsertTx and ReapTxs, the application can now own transaction admission and validation, while CometBFT focuses on consensus and networking. This keeps transaction-state decisions closer to execution and reduces the coupling between locking critical consensus operations and increased transaction throughput, ultimately leading to greater stability under load. This also aligns with the work behind Cosmos EVM’s Krakatoa release, discussed below.
Addition of libp2p
The second major change in CometBFT v0.39 is the addition and improvement of the experimental libp2p networking stack. The goal here was to improve CometBFT's handling of network traffic under load. The libp2p path enhances concurrent message handling and round-trip behavior without changing the consensus algorithm above it. Because libp2p ships with multiple network transports, including QUIC, it creates a stronger foundation for future networking improvements.
Improving the networking layer made the next set of bottlenecks easier to identify. Once networking constraints were reduced, the remaining pressure points in ABCI and mempool behavior became clearer, which helped focus the rest of the performance work in this release family.
Adaptive Sync
The third major change is Adaptive Sync. Adaptive Sync improves the recovery path for nodes that fall behind consensus. Lagging nodes should be able to keep syncing committed blocks, catch up, and rejoin normal operation without requiring manual recovery every time. By allowing block sync to run alongside consensus instead of treating those two modes as completely separate, Adaptive Sync improves recovery behavior for nodes operating under real-world conditions.
Taken together, the CometBFT changes give more power to application developers and help address key issues that validators and operators have faced at scale.
Cosmos SDK v0.54
Cosmos SDK v0.54 (Github release notes, documentation) brings two of the most important improvements in RF 2026.1: BlockSTM for parallel execution and a stronger telemetry framework through OpenTelemetry integration.
BlockSTM is the execution-layer upgrade in this release. At a high level, it allows transactions within a block to execute in parallel instead of forcing all execution through a purely serial path. For workloads that benefit from parallelism, this can significantly improve execution throughput while preserving deterministic behavior.
There are already strong signals from prior integrations that BlockSTM-style execution can materially increase throughput in production-oriented environments. In RF 2026.1, we have brought that work into the Cosmos SDK with native support, additional hardening, and better alignment with the rest of the stack.
We’d like to provide attribution to the original BlockSTM authors, Rati Gelashvili, Alexander Spiegelman, Zhuolun Xiang, George Danezis, Zekun Li, Dahlia Malkhi, Yu Xia, and Runtian Zhou. You can read their paper on Arxiv and see the repo on Github.
The other major SDK improvement is observability. Observability gives operators implementing performance improvements the ability to see where time is being spent and where systems break down under load.
The telemetry work in v0.54 treats OpenTelemetry as a first-class part of operating the stack for both engineers and operators. The broader observability work standardizes around OpenTelemetry-compatible export and ingestion, making it easier to plug stack telemetry into the tools teams already use to monitor production systems. The result is high-quality observability, enabling operators to see where time is spent and tune accordingly.
Cosmos EVM v0.7.0
Cosmos EVM v0.7.0 ships Krakatoa, our application-owned mempool implementation for the EVM (Github release notes, documentation).
The design moves more transaction handling into the application, including asynchronous transaction insertion, application-side rechecks, and application-managed transaction state. This reduces the amount of transaction-validation work happening directly in the consensus path.
For the EVM, that matters because mempool behavior is on the critical path of transaction execution. If insertion, rechecking, and sequence handling are too tightly coupled to the consensus reactor, throughput degrades and latency becomes unpredictable under load. Krakatoa addresses this by moving more consensus logic out of the consensus path to the application side, where it has direct access to the right state and avoids contention for consensus-critical locks.
Krakatoa is designed to achieve higher performance as part of the broader architecture in this release. It depends on the new CometBFT ABCI changes in RF 2026.1 and gives the application additional decision authority over transaction handling across the stack.
Performance
RF 2026.1 demonstrates 2,000+ transactions per second sustained with sub-second block times and predictable behavior under realistic load. In testing, the release sustained roughly 2,000 TPS on a 5-validator, 32-CPU network with BlockSTM and Krakatoa enabled. You can read more about our benchmarking methodology in this blog post.
The performance improvements in this release come from several parts of the stack working together:
- libp2p improves concurrent message handling in the CometBFT networking layer
- BlockSTM increases execution throughput in the SDK
- Cosmos EVM Krakatoa and the new ABCI changes in CometBFT reduce locking and contention in the transaction path
As a result, the Cosmos Stack delivers significantly improved throughput while also strengthening stability and operational behavior under load. For more information regarding our testing methodology, check out our blog post.
Enterprise Modules
RF 2026.1 expands the enterprise capabilities of the Cosmos Stack for teams operating in regulated environments, consortium chains, or enterprise networks with known operators. This release includes the new Proof-of-Authority Module (PoA) alongside an hardened and security audited Group Module, which remains an important part of enterprise governance use-cases, and is deployed by chains like Figure’s Provenance.
Proof-of-Authority Module
The Proof-of-Authority (PoA) module is a first-class, native governance option for ledger environments that use a set of permissioned operators. This design comes with some unique advantages:
- Network configurability: A configurable admin authority lets a selected administrator define operators and governance participants to satisfy security, compliance, and operational requirements.
- Token-free operation: Launch and govern a production network without the legal or operational complexity of creating or managing a native staking token.
- Future-proofed design: Move to other security models later to adapt to changing business needs, including a transition to proof-of-stake with a token.
In practice, PoA enables fine-grained operational control and auditability over the network. Every validator-power change, key rotation, and governance action is executed through explicit, administrator-controlled on-chain messages, resulting in a clear history for internal security reviews and external compliance audits. Click here to read the documentation for the PoA module.
Group Module
The Group Module provides enterprise teams with programmable, automated, and auditable governance that saves time and streamlines operations. It offers a resilient and flexible way to set up decision-making processes that reflect business reality, with automation features that reduce overhead for enterprise operators.
Examples of customers who benefit from this type of automated governance include banking consortia, compliance committees, and multi-party trade financing workflows.
Features of the Group module comprise weighted voting that reflects real stakeholder structures, decision policies that can vary by action type, a proposal lifecycle with built-in review windows and safety mechanisms, and an immutable on-chain record of every vote cast and every decision made.
Together, PoA and the Group Module expand the product surface of the Cosmos Stack for enterprises and institutions that require end-to-end control and governance of their ledger.
Upgrade Considerations
Teams planning an upgrade to RF 2026.1 should review how the release family’s validated components interact with any custom application logic or surrounding infrastructure, test application behavior under the new mempool and execution model, and validate observability pipelines before moving to production.
In particular, teams should:
- Review pinned component versions and supported combinations in the release family documentation.
- Test any application-specific transaction handling assumptions against the new mempool and ABCI behavior.
- Validate monitoring and telemetry pipelines against the updated OpenTelemetry-based instrumentation.
- Benchmark with production-like workloads before rollout.
- Plan phased upgrades where possible for validator and operator environments.
Because RF 2026.1 is designed as a coordinated release family, the upgrade is designed for teams to adopt the validated component set rather than selectively mixing versions. Access the SDK upgrade guide here, and the EVM upgrade guide here.
Closing
RF 2026.1 makes the Cosmos Stack easier to run in production, faster under load, easier to upgrade, and better suited to teams that need control, auditability, and predictable operations.
Together, these upgrades deliver a more coherent product for teams that need performance, stability, and supportability.
We also plan to publish deeper technical breakdowns of the major changes in RF 2026.1, including the CometBFT work, BlockSTM, Krakatoa, and the enterprise modules.
