Cronos v1.8: Reading an Empty Pending-Transaction Feed
Cronos’s upgrade checkpoint has passed. Its optional application-side mempool changes where pending transactions can be seen—and what an empty response actually means.
AI-generated conceptual illustration: a technician turns toward a populated compartment beside an empty one. It symbolizes different views of a pending-transaction pool, not an observed outage or a real Cronos interface.
Key Points
- Chainstack recorded upgrade maintenance complete at 08:00 UTC on October 22. Cronos Explorer shows the target block, 101,485,000, timestamped 07:52:24 UTC and linked to its successor.
- The application-side mempool is opt-in. With it enabled, some older pending-transaction views are empty while txpool methods read the application’s queue.
- Queue management, parallel execution and experimental networking are separate changes. A passed upgrade checkpoint does not establish universal configuration or measured performance.
Chronological Timeline
The release is marked Pre-release and warns operators not to replace their binary immediately.
The announcement schedules October 22 and separates the optional mempool from parallel execution and experimental libp2p.
Block 101,485,000 carries a 07:52:24 UTC timestamp; Chainstack’s maintenance completion entry is at 08:00 UTC. These are different records.
A checkpoint has passed; the records have different meanings
Cronos scheduled its EVM v1.8 mainnet upgrade for October 22, 2026. There is now more to inspect than that date: Chainstack’s maintenance notice names block 101,485,000 and records completion at 08:00 UTC. Cronos Explorer displays that block with a 07:52:24 UTC timestamp, and block 101,485,001 points back to its hash. The announced checkpoint has been crossed in the explorer’s history.[1][3][4][5]
Those observations have limits. The block timestamp is a chain record; 08:00 is the provider’s maintenance entry, not a measured network-wide activation instant. CoinYQ did not independently verify the running software version across validators. The release page also still labels v1.8.0 a Pre-release. Neither that label nor a maintenance badge alone establishes which options every operator enabled.[3][4][5][6]
Two views of one node’s waiting room
One option has a consequence that readers of transaction feeds can easily miss. A mempool holds transactions waiting to enter a block. Previously, Cronos used the CometBFT consensus layer’s pool; v1.8 lets an operator give that job to the application instead. The migration guide describes this as an opt-in change, with existing configurations continuing to work.[2]
The choice changes the window through which the queue is visible. In app mode, CometBFT’s /unconfirmed_txs and /num_unconfirmed_txs return no pending entries; eth_newPendingTransactionFilter and the pending filter also return nothing, according to the guide. The txpool_content and txpool_status methods read the application pool instead. In flood mode, CometBFT’s pending view works while those txpool methods see an empty application pool. An empty result from one interface therefore cannot, by itself, establish that the node has no waiting transactions.[2]
Moving work before the block, and parallelizing work inside it
Why move the pool at all? Cronos’s announcement describes shared work between admission and block construction, with less repeated verification. Revalidation after a block can run in the background rather than compete on the consensus path. This is a change to how work is organized before the next block, not evidence that a submitted transaction has already been included or finalized.[1][2]
Block-STM addresses another stage: executing transactions within a block in parallel and re-executing affected transactions when conflicts are detected. Cronos recommends it in the migration guide, but the documented block-executor default is sequential. The software version, the selected pool and the selected execution mode are separate pieces of information. Enabling the application pool also needs a compatible capacity setting; the documented disabled value, max-txs = -1, cannot be paired with app mode.[1][2]
What the upgrade does not settle by itself
Other release headlines need the same care. The October 14 announcement describes libp2p support as experimental and not yet enabled on mainnet; the presence of that code in v1.8 does not establish later activation. The migration guide likewise says the 16,777,216 per-transaction gas cap needs a separate governance change rather than taking effect at the upgrade height. We have not verified either subsequent change here.[1][2]
For anyone building a dashboard or investigating a waiting transaction, the practical question is which pool the endpoint exposes. The guide tells operators to retain flood mode for consumers that need the older pending view, or move consumers to txpool methods with that namespace enabled. The new checkpoint makes this operational distinction timely. It does not turn an empty feed into proof of a quiet network, nor substitute for measurements of actual execution and query latency.[2][3][4]
Continue reading
Explore the topic through other cases and contexts.
Sources & References
- [1]Source 1: Cronos Labs — Cronos EVM Mainnet v1.8 UpgradeCronos Labs · 2026-10-14Accessed 2026-10-22
- [2]Source 2: Cronos v1.8.0 — migration guide, pending-transaction views and defaultsCronosAccessed 2026-10-22
- [3]Source 3: Chainstack — Cronos Mainnet Upgrade maintenance recordChainstackAccessed 2026-10-22
- [4]Source 4: Cronos Explorer — block 101,485,000Cronos ExplorerAccessed 2026-10-22
- [5]Source 5: Cronos Explorer — block 101,485,001 and parent hashCronos ExplorerAccessed 2026-10-22
- [6]Source 6: Cronos — v1.8.0 release notesCronos · 2026-09-24Accessed 2026-10-22