The Cronos blockchain, an EVM-compatible chain built on the Cosmos SDK, has successfully completed its v1.8 mainnet upgrade on October 22, integrating its parallel execution engine, Block-STM, directly into the core Cosmos SDK layer. This significant architectural shift aims to bolster the network’s processing capabilities. However, while Cronos leadership previously highlighted ambitious performance projections, including claims of approximately 20% faster median block times and up to 66% higher sustained throughput, these figures, derived from simulations and shared on social media in September, are notably absent from the official v1.8 blog post and release notes. Furthermore, the current state of network utilization on Cronos presents an immediate challenge in validating the throughput claims, as on upgrade day, roughly three out of every four blocks contained no transactions, rendering any capacity gains largely unobservable.
The Journey to v1.8: A Chronology of Performance Enhancements
Cronos, launched by Crypto.com, emerged as a critical component in the broader Cosmos ecosystem, designed to offer an Ethereum Virtual Machine (EVM) compatible environment with the scalability and interoperability benefits of the Cosmos framework. Its ambition has always been to attract a wide array of decentralized applications (dApps) and users by providing a high-performance, low-cost alternative to other Layer 1 blockchains. This goal has driven a series of architectural refinements and upgrades aimed at enhancing network speed and capacity.
The pursuit of superior performance is not new for Cronos. In a previous major upgrade around mid-2022, the network dramatically reduced its block time from approximately 5.6 seconds to under one second, marking a near tenfold improvement. This foundational enhancement set the stage for subsequent optimizations. Parallel execution, a technique designed to process multiple transactions concurrently, first made its appearance in Cronos v1.4. While a significant step, its integration at that time was not as deeply embedded as with the current v1.8 release.
The current v1.8 upgrade represents the culmination of this ongoing effort, particularly in maturing Block-STM. The timeline leading to the mainnet activation saw key milestones. In late September, a social media post from Cronos Network explicitly stated the anticipated performance boosts: "~20% faster median block times" and "up to 66% higher sustained throughput," clarifying that these figures were based on "mainnet simulations." Following this, the testnet upgrade went live on September 30, with Cronos reiterating the 20% block-time claim, though notably omitting the throughput figure in that specific context. The final mainnet activation was officially set for October 22, transitioning these architectural improvements from test environments to the live production chain.
Under the Hood: Technical Deep Dive into Cronos v1.8
The core innovation driving Cronos v1.8 is the full integration of Block-STM, Cronos’s proprietary parallel execution engine. Unlike traditional blockchain architectures where transactions are processed sequentially, Block-STM employs an optimistic concurrency model. This means it attempts to run a block’s transactions simultaneously, operating under the assumption that most will not conflict by trying to modify the same state. In instances where conflicts do arise—for example, two transactions attempting to spend the same unspent transaction output (UTXO) or modify the same smart contract variable—the engine detects these conflicts and re-runs the conflicting transactions sequentially. This approach aims to maximize transaction processing efficiency, especially under high network load with diverse transaction types. The significance of v1.8 lies in moving Block-STM from a higher application layer directly into the Cosmos SDK layer, allowing for deeper system-level optimizations and potentially more efficient resource utilization.
Beyond Block-STM, the v1.8 upgrade encompasses a comprehensive overhaul of several foundational components, reinforcing Cronos’s position within the broader blockchain ecosystem:
- Cosmos SDK v0.54.3: The underlying framework for building application-specific blockchains. Upgrading to the latest SDK version brings improvements in module development, security, and overall framework stability, ensuring Cronos benefits from the continuous advancements within the Cosmos ecosystem.
- CometBFT v0.39: The consensus engine formerly known as Tendermint. CometBFT is crucial for block finality and network security. This upgrade likely introduces performance enhancements, bug fixes, and potentially new features related to consensus reliability and speed.
- IBC-Go v11: The Inter-Blockchain Communication (IBC) protocol is fundamental to the Cosmos vision of an internet of blockchains. Upgrading IBC-Go ensures Cronos maintains robust, secure, and efficient interoperability with other IBC-enabled chains, facilitating asset transfers and cross-chain communication.
- RocksDB v10.9.1: A high-performance embedded database, often used for storing blockchain state. An upgrade to a newer version typically brings optimizations in data storage, retrieval speeds, and overall database management, which are critical for node performance and chain synchronization.
However, the v1.8 release also introduces several breaking changes that developers and users must be aware of. The SendCroToIbc function, which facilitates the transfer of CRO tokens via IBC, is now limited to authorized contracts, enhancing security by restricting arbitrary transfers. Interchain Accounts (ICA), a feature allowing one blockchain account to control an account on another chain via IBC, have been removed. Additionally, MsgTurnBridge is no longer supported, impacting specific bridge functionalities. Lastly, governance parameter bounds have been tightened, indicating a move towards more conservative and secure on-chain governance mechanisms. These changes necessitate adaptation from dApp developers and potentially impact user workflows.
A notable point of divergence surfaced regarding the network’s underlying communication layer. The GitHub release notes for v1.8 stated that the upgrade "replaced the legacy networking stack with libp2p," promising "greatly reduced latency." In contrast, the official Cronos blog post accompanying the mainnet announcement indicated that libp2p is still experimental and "not enabled on mainnet." This discrepancy implies that any potential latency gains attributed to a new networking layer would not apply to the current mainnet deployment, raising questions about the full scope of immediate performance improvements.
Furthermore, for Block-STM to fully deliver its parallel execution capabilities, node operators must configure their nodes appropriately. The engine’s functionality depends on specific settings such as block-executor, block-stm-workers, and block-stm-pre-estimate. Nodes that continue to rely solely on older [evm] settings might revert to running transactions sequentially, thus negating the benefits of parallel execution. The Cronos blog strongly recommends Block-STM for "all node types" and directs operators to follow the v1.8 migration guide. A new requirement also mandates operators to review json-rpc.txfee-cap, which is now enforced on eth_sendRawTransaction. The actual real-world performance on mainnet will therefore be contingent on the proactive adoption of these new configurations by a significant number of validators.
Scrutinizing the Claims: 20% Faster Blocks and 66% Higher Throughput
The performance figures—a 20% reduction in median block times and up to 66% higher sustained throughput—first emerged in a Cronos social media post in late September. The post explicitly stated that these numbers were derived from "mainnet simulations," suggesting theoretical capabilities under specific, controlled conditions. However, a critical observation is the absence of these specific benchmark numbers, or any detailed performance data, in the official v1.8 mainnet blog post or the v1.8.0 release notes on GitHub. The blog post offers only a general statement, claiming that Block-STM "delivers the best block-execution performance available on Cronos," without providing empirical evidence. Similarly, the GitHub release mentions "lower peer-to-peer latency and faster block turnaround from the mempool change" but publishes no concrete measurements to substantiate these claims.
This lack of transparency regarding the benchmark methodology is a significant concern. Neither document provides details about the baseline performance used for comparison, the specific test conditions under which the simulations were run, nor the transaction mix employed. Without such crucial context, it becomes exceedingly difficult for external observers to verify the claims or understand their real-world applicability. In a space that values decentralization and verifiable truth, the absence of detailed, reproducible benchmarks can erode trust and make it challenging for the community to assess the true impact of an upgrade.
Analyzing the 20% Block Time Claim:
The claim of "~20% faster median block times" is, at least in theory, more immediately verifiable than the throughput claim, given current network conditions. Cronos has already achieved remarkable speed, cutting its block time to under one second in a previous upgrade. As of October 22, after the v1.8 upgrade, the Cronos explorer showed an average block time of approximately 0.5018 seconds at block 101,555,365. For a 20% speed increase to be evident, the average block time before the upgrade would need to have been around 0.63 seconds (0.5018 / 0.80). If Cronos was consistently producing blocks every 0.6 seconds or slightly longer prior to v1.8, then a subsequent average of 0.5018 seconds would indeed support the claim. However, if the network was already operating closer to the half-second mark before the upgrade, then the observed post-upgrade average would suggest that the promised gain has not yet materialized, or is less pronounced than claimed.
Two important caveats apply to this direct comparison. Firstly, the Cronos explorer does not explicitly state the duration over which its displayed average block time is calculated, which could influence the immediate post-upgrade figures. Secondly, Cronos’s original claim refers to "median" block time, which represents the middle value in a sorted list of block times and is less susceptible to outliers (a few unusually slow blocks) than the "average" block time. Nonetheless, the average is the most readily available public metric post-upgrade and provides a clear quantitative target for before-and-after verification.
A technical challenge arises when attempting to verify block times directly from EVM block timestamps, as these are typically recorded in whole seconds. With Cronos producing approximately two blocks per second, many consecutive blocks will share the same timestamp, making fine-grained comparisons impossible. The more reliable method, as highlighted by independent analysts, is to count the total number of blocks produced over a fixed time window. For instance, the Cronos explorer’s transaction chart provides daily block counts. By dividing 86,400 seconds (the number of seconds in a day) by the total block count for that day, one can derive the average block time for the period. If v1.8 truly delivers a 20% speed increase, meaning blocks are 20% shorter, then approximately 1.25 times as many blocks should be produced per day. On a pre-upgrade pace of about 0.63 seconds per block (roughly 137,000 blocks per day), the post-upgrade daily block count should rise to approximately 172,000 blocks (137,000 * 1.25). This method offers a cleaner, more statistically robust test of the block time claim over a full 24-hour period before and after the upgrade.
The Unverifiable 66% Throughput Claim:
In stark contrast to the block time, the claim of "up to 66% higher sustained throughput" cannot be meaningfully assessed under the current network conditions. Throughput, which measures the number of transactions a network can process per unit of time (e.g., transactions per second, TPS), only becomes a limiting factor when there is sufficient demand to fill blocks. The current state of the Cronos network reveals a significant underutilization of its existing capacity.
On October 22, by the time of analysis, the Cronos chain had processed a mere 33,253 transactions across 137,087 blocks. This equates to an average of approximately 0.24 transactions per block, meaning that roughly three out of every four blocks produced were entirely empty. The average block size was also extremely small, at just 2,221 bytes. Looking back over the past month, the explorer’s transaction chart shows daily activity fluctuating between roughly 30,000 and 93,000 transactions. Even on the busiest day within that period, this translates to an average of about one transaction per second on a chain designed to produce approximately two blocks per second.
When a blockchain network operates with less than one transaction per block, it is effectively running at a fraction of its capacity. In such a scenario, any increase in the maximum potential throughput, such as a 66% gain, simply cannot be observed. Whether the underlying engine can handle 35 transactions per second or 350 transactions per second, the on-chain data will look largely identical if the actual transaction volume is only 1 TPS. Under these conditions, the only ways to verify sustained throughput gains would be through controlled stress tests—the very simulations Cronos claims to have already run—or a sudden and significant surge in organic network demand that pushes the chain’s capacity limits. This situation does not diminish the technical achievement of integrating Block-STM; parallel execution is most impactful when blocks are densely packed with transactions that do not conflict. However, with Cronos’s blocks largely empty today, there is simply no workload for the parallel execution engine to optimize.
Broader Implications and The Path Forward
The v1.8 upgrade and the subsequent discussion around its performance claims highlight several crucial aspects for Cronos and the broader blockchain industry. For any Layer 1 blockchain, performance metrics like block time and throughput are paramount. They directly influence user experience (faster transactions, lower latency), developer adoption (attracting dApps that require high scalability), and overall network competitiveness against a rapidly evolving landscape of high-performance chains. Unverified or poorly communicated performance claims, even if technically achievable in simulations, can lead to skepticism and impact trust within the community and among potential users.
The importance of transparency in reporting benchmarks cannot be overstated. Clear, reproducible methodologies, including baselines, detailed test conditions, and transaction mixes, are essential for fostering confidence and allowing independent verification. This is particularly true in the crypto space, where technical claims often drive narrative and investment decisions. Cronos, as an EVM-compatible chain within the interoperable Cosmos ecosystem, is strategically positioned to attract liquidity and innovation. Its ability to demonstrate robust, verifiable performance is key to realizing this potential.
Moving forward, the focus will be on two key areas. Firstly, monitoring the average daily block count on the Cronos explorer will provide the most accessible method for verifying the 20% block time claim over the coming days and weeks. A sustained increase in daily block production, aligning with the 25% expectation, would be a strong indicator of success. Secondly, for the 66% throughput claim, Cronos will require either a significant surge in organic network activity or the publication of detailed, reproducible stress test results. As more validators adopt the recommended node configurations to fully activate Block-STM, the network’s actual capacity will become more apparent. The ultimate success of v1.8 will hinge not just on the technical implementation of parallel execution, but on Cronos’s ability to attract sufficient demand to truly test and showcase its enhanced capabilities, backed by transparent and verifiable performance data.
Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services.
Follow us on Twitter @themerklehash to stay updated with the latest Crypto, NFT, AI, Cybersecurity, and Metaverse news!
