Cronos says v1.8 delivers about 20% faster blocks and up to 66% higher throughput. Neither number appears in the official v1.8 blog post or release notes. Both come from a September social media post and were based on simulations.
Today, the upgrade is scheduled to move those claims onto a live chain, and Cronos’s own explorer shows why only one of them can be checked. On upgrade day, about three out of four Cronos blocks contain no transactions. A throughput gain has nothing to show up in when the blocks are mostly empty.
Cronos v1.8 Reaches Mainnet With Parallel Execution Built In
The Cronos EVM v1.8 mainnet announcement set the upgrade for October 22. The main change is that Block-STM, Cronos’s parallel execution engine, has reached “full maturity” and is now built directly into the Cosmos SDK layer.
Block-STM runs a block’s transactions at the same time, on the assumption that they won’t affect the same state. If two transactions conflict, the engine re-runs them one after the other. As I covered in my earlier breakdown of how v1.8 embeds the engine, parallel execution isn’t new to Cronos. It first arrived in v1.4. What changes in v1.8 is where it sits in the stack.
The release also includes:
- An optional app-side mempool, which lets the application layer take over transaction management from CometBFT
- Floor-data-gas, a minimum gas cost for transactions with heavy calldata
- EIP-1559 balance checks enforced during block execution, not just when transactions are first checked
- The Osaka hardfork, enabled through go-ethereum v1.16.9
- Over 90% EVM API equivalence, covering more than 80 Ethereum API methods
- More than 40 bug fixes
The upgrade moves Cronos to Cosmos SDK v0.54.3, CometBFT v0.39, IBC-Go v11 and RocksDB v10.9.1. It also has breaking changes. SendCroToIbc is limited to authorized contracts, Interchain Accounts are removed, MsgTurnBridge is no longer supported, and governance parameter bounds are tighter.
Where the 20% and 66% Figures Come From
The performance figures first appeared in a Cronos post in late September. It promised “~20% faster median block times” and “up to 66%” higher sustained throughput. Coverage at the time said both figures came from mainnet simulations. When the testnet upgrade went live on September 30, Cronos repeated the 20% block-time claim but not the throughput figure.
What’s missing is the evidence. The mainnet blog post has no benchmark numbers, and its only performance claim is that Block-STM “delivers the best block-execution performance available on Cronos.” The v1.8.0 release on GitHub mentions lower peer-to-peer latency and faster block turnaround from the mempool change, but publishes no measurements either. Neither document gives a baseline, test conditions, or the transaction mix used in the simulation.
There’s also a small conflict between the two documents. The GitHub release says v1.8 “replaced the legacy networking stack with libp2p,” which it says greatly reduces latency. The blog post says libp2p is experimental and not enabled on mainnet. So any latency gains from the new networking layer don’t apply to today’s mainnet upgrade.
A 20% Gain on Top of Half-Second Blocks
The key context for the block-time claim is the starting point. Cronos cut its block time from about 5.6 seconds to under one second in a mid-2025 upgrade, targeting a tenfold reduction.
The Cronos explorer now shows an average block time of 0.5018 seconds, at block 101,555,365 on the evening of October 22. For that figure to be 20% faster than before the upgrade, the previous average would have to be about 0.63 seconds. That makes the comparison easy to test: if Cronos was producing a block roughly every 0.6 seconds before today, the claim holds up. If it was already near half a second, v1.8 hasn’t yet produced the gain it promised.
Two cautions apply. The explorer doesn’t say how long a period its average covers. And Cronos’s claim is about median block time, which shows a typical block, not the average, which a few slow blocks can push up. Even so, the average is the first public post-upgrade number, and it gives a clear target for the before-and-after check.
Why the 66% Throughput Claim Can’t Show Up Yet
Throughput only shows its limit when there’s enough demand to fill blocks. Cronos’s explorer shows how far it is from that point.
On October 22, by the time of checking, the chain had produced 137,087 blocks carrying 33,253 transactions. That’s about 0.24 transactions per block, which means roughly three out of four blocks were empty. The average block was just 2,221 bytes.
The past month looks similar. The explorer’s transaction chart shows daily activity between roughly 30,000 and 93,000 transactions. Even on the busiest day, that’s about one transaction per second, on a chain producing about two blocks every second.
A chain carrying less than one transaction per block can’t show whether its capacity rose by 66%. On-chain data looks the same whether the engine can handle 35 transactions per second or 350. Under current conditions, the only way to test sustained throughput is a stress test or a sudden demand spike, which is the kind of simulation Cronos already says it ran.
That’s not a criticism of Block-STM. Parallel execution matters most when blocks are full of transactions that don’t conflict with each other. Cronos’s blocks today are mostly empty, so there’s nothing to run in parallel.
The Node Settings That Decide Whether Parallel Execution Runs
There’s one more variable. Block-STM depends on node configuration through settings such as block-executor, block-stm-workers and block-stm-pre-estimate. Nodes that still rely only on older [evm] settings may fall back to running transactions one at a time.
Cronos’s blog recommends Block-STM “for all node types” and tells operators to follow the v1.8 migration guide. It also flags a new requirement: operators need to review json-rpc.txfee-cap, which is now enforced on eth_sendRawTransaction. Real-world results on mainnet will depend on how many validators actually switch the engine on.
How to Check the Block Time Yourself
There’s a technical catch here. EVM block timestamps are recorded in whole seconds. At about two blocks per second, pairs of blocks share the same timestamp, so comparing timestamps block by block can’t show a 20% change.
The reliable method is to count blocks over a fixed time window. The Cronos explorer’s transaction chart makes this simple: each day’s tooltip shows a total block count. Divide 86,400 seconds by that count to get the day’s average block time.
A full day before the upgrade compared with a full day after it is the cleanest test. If v1.8 delivers what Cronos says, the post-upgrade day should contain about 25% more blocks, since blocks that are 20% shorter mean 1.25 times as many per day. On a pre-upgrade pace of about 0.63 seconds per block, that’s roughly 137,000 blocks a day rising to about 172,000.
Block time is the one claim v1.8 can actually pass or fail this week. For the 66% throughput claim, Cronos needs more traffic before anyone can check it.
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!