Optimism just shipped ZK dispute game monitoring. The multi-prover roadmap is quietly becoming operator infrastructure.
Four releases, all labeled optional or prep work. The one that matters is monitoring for a ZK dispute game contract that isn't live yet.
CryptoVibe Desk · optimism · fault-proofs · op-stack
- →Optimism shipped four releases this week, including ZK dispute game type 10 monitoring in op-dispute-mon and interop scaffolding across op-reth and op-proposer.
- →Optimism shipped the ZK dispute monitor before the contract goes live, meaning observability infrastructure is ready before the multi-prover switch flips.
- →Operators running op-dispute-mon should test their config for type-10 game handling now, before Optimism deploys the ZK dispute contract on any mainnet.
- ZK dispute game → A smart contract that settles arguments about a rollup's state using a zero-knowledge proof instead of a multi-round interactive challenge.
- fault proof → A mechanism that lets anyone challenge a wrong state claim posted to Ethereum by an optimistic rollup, forcing the chain to prove it was correct.
- FCU (forkchoice update) → A signal from Ethereum's consensus layer telling execution clients which block is the current canonical chain head.
Optimism's op-dispute-mon v1.5.2 adds ZK dispute game support, per the release notes. Type 10 is the game being watched. It isn't live on-chain yet.
Four releases landed this week, all marked optional or preparatory. That one is worth reading. The existing dispute games run an interactive bisection protocol: challenger and defender narrow a disagreement to a single instruction, which L1 executes.
A ZK dispute game replaces that back-and-forth with a validity proof. The monitor needs different logic for each game type. Optimism shipped the observability layer first.
The other three releases fill in the picture. op-reth v2.2.5 bumps the reth dependency for an FCU backfill-target fix and adds an interop_ RPC namespace. The FCU fix is maintenance. The interop_ namespace is the execution-client side of Optimism's cross-chain messaging system, appearing in the client before the feature is active.
op-proposer v1.16.3 is mostly prep for a future interop release, according to Optimism's notes. Operators not running interop chains get an op-geth dependency bump and little else. op-deployer v0.7.0-rc.1 is still a release candidate.
The tradeoff is familiar. Shipping monitoring before the contract it watches means operators carry extra code before the feature lands. That's the right call. Observability layers should be ready before the switch flips, not built under pressure afterward.
If you're running op-dispute-mon, confirm your config handles type-10 games. The update is not passive.
Read the PR diff, not the thread. The announcement will still call this a routine maintenance cluster. The release notes say the dispute monitor now watches a new game class and the execution client just grew an interop namespace.
That's not maintenance. That's the catch.
If you run an OP Stack chain, none of these upgrades are urgent today. When ZK dispute game type 10 goes live on-chain, the operators who skipped the config check will be the first to know.
Optimism's decision to ship type-10 dispute monitoring without a target deployment date is the engineering team knowing something the operator docs don't say yet.
A developer forum post or onchain governance proposal naming a deployment date for ZK dispute game type 10 on an OP Stack mainnet. Within 6 months.
Primary links and supporting reads used by the desk for this story.
Forward this.
