Optimism just fixed a safety bug. The timing makes it bigger than a patch.
Kona is about to become the main fault-proof program for OP Stack chains, so this bug moved from edge case to live security dependency.

CryptoVibe Desk · optimism · op-stack · fault-proofs

- →Optimism released kona-client v1.6.0 and kona-host v1.6.0 on June 19 as critical updates for OP Stack operators.
- →The bug made Kona derive a different output root once data use passed a threshold operators could not easily see.
- →Before Karst goes live, the upgrade question is simple: every serious OP Stack operator needs the patched proof path.
- Fault proof → A fault proof is the system that lets someone challenge a wrong Layer-2 result on Ethereum.
- Dispute game → A dispute game is the step-by-step challenge process used to prove which chain result is correct.
- BLOBBASEFEE → BLOBBASEFEE is an Ethereum value that tells contracts the current fee for blob data.
- Blob gas → Blob gas measures how much blob data a block uses, separate from normal transaction gas.
Kona derived BLOBBASEFEE wrong after Jovian.
Optimism fixed that on June 19 with kona-client v1.6.0 and kona-host v1.6.0. Both releases are marked as critical security fixes. The timing matters because Upgrade 19, also called Karst, promotes kona-client to the primary OP Stack fault proof program.
At the contract level, the bug is narrow. Post-Jovian, the parent header's blobGasUsed field carries the data-availability footprint. Kona used that value to derive BLOBBASEFEE. Once the parent footprint passed about 4.26M blob gas units, the kona-host release notes say BLOBBASEFEE could rise above 1.
That is not what the canonical clients do. Per the release notes, op-geth and op-reth both pin BLOBBASEFEE to 1 for Ecotone-plus blocks. So Kona could compute a different state root than the nodes producing the chain. In a dispute game, that breaks the point of the game.
If you're running OP Stack infrastructure, this is not a cosmetic upgrade. A challenger using the old Kona path could land on a different output root. The chain might be fine, but the proof program would be arguing from the wrong execution trace. That's the catch.
The host fix is less flashy but still important. kona-host previously fetched debug_executePayload and optimistic re-execution hints once. If that failed, it fell back to debug_dbGet, which op-reth does not implement. v1.6.0 routes those hints through the get_preimage retry loop instead.
This is a backpressure problem, not a consensus problem. One transient preimage fetch should not become a terminal proof failure. The engineers know this. The release changes the host path so missing data gets retried instead of turning into a dead end.
Karst raises the cost of ignoring this. The governance proposal says kona-client becomes the primary fault proof program and CANNON_KONA becomes the respected game type for permissionless fault proof chains. It also says OP Stack operators must move off op-geth and op-program before activation.
The release notes also add real superchain-registry dependency sets for interop proofs. Before this, the empty dependency list forced an insecure production fallback. That is groundwork, but it points the same way. OP Stack security is moving from one proof path toward a multi-proof world, and every path has to derive the same root.
The patch does what the announcement says, plus one uncomfortable reminder. Fault proofs are only sound when the boring derivation details match exactly. Miss one fee field at one data threshold, and the numbers don't add up.
The patch is public. The activation window is set. Any OP Stack operator still on the unfixed kona path when Karst lands is not running a backup proof program, they're running a broken one.
Before the July 8, 2026 mainnet L2 activation, watch whether OP Labs publishes a final required-version matrix that lists kona-client v1.6.0 or newer for every Karst chain.
Primary links and supporting reads used by the desk for this story.
Forward this.











