ethereum-optimism / ethereum-optimism/optimism

[SuperZKDG] Remove `ZK_DISPUTE_GAME` dev feature flag and address TODOs once ZK becomes the default game post-interop

Open
#21,529 0 comments 0 reactions 1 assignee View on GitHub

@0xarktos is already working on this.

Since Jul 3, 2026.

M-needs-triage
Dominant language
Go
Stars
6.5k
Forks
4k
Avg merge
2d 18h
Merged PRs (30d)
134

Description

Description

After the interop migration, ZKDisputeGame is expected to become the default super game.

Right now, the ZK game lives behind the ZK_DISPUTE_GAME flag, while the migration paths for multi-chain game migrations live behind both this flag and the OPTIMISM_PORTAL_INTEROP flag. When the interop migration lands, we need to remove these gates together while ensuring that validation remains intact for future upgrades.

Specifically:

  • In OPContractsManagerMigrator.sol (setInteropDisputeGames), drop the ZK_DISPUTE_GAME dev-feature gate, and remove the OPContractsManagerMigrator_ZKDisputeGameNotEnabled error if unused.

  • In StandardValidatorUtils.sol (assertValidNonSuperRootDisputeGames), add the ZKDG-NOSHAPE check so ZK_DISPUTE_GAME can never be registered on non-super-root chains.

  • In OPContractsManagerStandardValidator.sol (assertValidZKDisputeGame), remove the early return so chains without a ZK game registered fail validation, since ZK will be the default and will no longer be opt-in per chain.

  • Depending on the intended configuration for migrating multiple chains from SFDG to ZK, assertValidSuperRootDisputeGames may fail during an OPContractsManagerStandardValidator.validate() call.

    However, assertValidSuperRootDisputeGames is gated by the SUPER_ROOT_GAMES_MIGRATION flag. In a post-interop environment where migration to ZK is expected, this will need to be reordered or reassessed. Alternatively, the migration script config may need to keep all super game implementations intact in the DisputeGameFactory and not clear them.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.