BTCLiveETHLiveSOLLiveXRPLiveBNBLiveDOGELiveADALiveAVAXLive

BREAKING NEWS ▶

8 Oct Cardano update: CIP-0113 programmable tokens go live on mainnet with CMTA recognition◆

CHARTING PARTNERTradingViewAdvanced charts, indicators and market tools.OPEN CHARTS →

Start with today’s trader mapBefore you leave: see the cross-asset levels, confirmations, invalidations and catalysts NetNapz is tracking for the next session.DAILY TRADER BRIEF →STRATEGY DESK →

Optimism op-reth 2.8.0 Fixes Invalid-Block Handling; Paired Kona Upgrade Required

The execution-client release changes how invalid derived blocks are handled. Operators pairing it with kona-node face a coordinated upgrade requirement, while Kona remains unsuitable for production.

Published 28 October 2026. Reporting checked 28 October 2026, 12:17 UTC. Releases dated 27 October.

Official Optimism wordmark from Optimism brand assets, used for editorial identification. Trademark belongs to its owner; not an event photograph.

Optimism published op-reth 2.8.0 on 27 October and recommends it to operators. The release rejects invalid derived transactions so the rollup node can substitute a deposits-only block, rather than build a result rejected by the fault-proof program.

A compatibility dependency matters

The companion kona-node 1.9.0 release handles that rejection. Earlier Kona versions repeatedly retry the invalid attributes, potentially stalling safe-head progress. Operators using the pair must upgrade Kona before or alongside op-reth.

Kona's release notice explicitly says it is not production-ready and directs production deployments to op-node. The paired upgrade instruction does not change that warning.

Configuration and storage require review

Op-reth also removes block-access-list flags and the older historical-proofs format. The main database's separate Storage V1 format remains deprecated, with support due to end in January 2027. Operators should distinguish those two storage changes and consult the full release instructions before migration.

Kona 1.9.0 additionally requires a configured signer for sequencers and validates existing key files at startup. Neither release changes existing chains' hard-fork activation times.

NetNapz assessment

This is a compatibility and operational-correctness development, not evidence of a new network activation. Reviewing an execution client in isolation can miss a dependency in its paired rollup node; test deployments should validate that combination before rollout.

NetNapz has not measured adoption or independently reproduced the fixes. The release notices do not establish the extent of any production incident, and provide no basis for attributing OP prices or token flows to the changes. Available software and verified deployment remain separate questions.