contracts-bedrock: Bump OPCM major version to 8.0.0 for U20 - #22096
Open
ajsutton wants to merge 2 commits into
Open
contracts-bedrock: Bump OPCM major version to 8.0.0 for U20#22096ajsutton wants to merge 2 commits into
ajsutton wants to merge 2 commits into
Conversation
U20 is a new sequential upgrade, and the OPCM versioning rules require a major bump for each one. Without this the release would be tagged against an OPCM still advertising the U19 major. The rule is documented in book/src/policies/versioning.md and restated on version() itself.
The upgrade allowances in _isPermittedInstruction are scoped to a single upgrade by requiring version() < NEXT release. Bumping OPCM to 8.0.0 made that guard false, so the DelayedWETH permitted proxy deployment and the super-root migration startingAnchorRoot override were both rejected, failing every fork upgrade test, the ZK super-root migration tests and the op-deployer chain upgrade. Both allowances are still needed by U20, so move the guard to 9.0.0. The 7.0.0 bump in #18631 did the same. The upgrade sequence check keeps its 8.0.0 threshold: mainnet and sepolia are both on OPCM 7.1.17, so 8.0.0 is a permitted next major.
maurelian
reviewed
Jul 29, 2026
Comment on lines
365
to
366
| if (_isMatchingInstruction(_instruction, Constants.PERMITTED_PROXY_DEPLOYMENT_KEY, "DelayedWETH")) { | ||
| return true; |
Contributor
There was a problem hiding this comment.
We should be able to remove this now since it went out with the last OPCM.
maurelian
reviewed
Jul 29, 2026
Comment on lines
369
to
372
| // Super root games migration requires overriding anchor root. | ||
| if (isDevFeatureEnabled(DevFeatures.SUPER_ROOT_GAMES_MIGRATION)) { | ||
| if (_isMatchingInstructionByKey(_instruction, "overrides.cfg.startingAnchorRoot")) return true; | ||
| } |
Contributor
There was a problem hiding this comment.
We should keep this since it's still a dev feature.
Contributor
There was a problem hiding this comment.
Unless it has been deployed but we just haven't removed the feature flag yet, but I don't think that's the case.
maurelian
reviewed
Jul 29, 2026
| // respected game type to correspond to an enabled game config. | ||
| if (_isMatchingInstructionByKey(_instruction, "overrides.cfg.startingRespectedGameType")) { | ||
| return true; | ||
| } |
Contributor
There was a problem hiding this comment.
I'm less confident about what to do here. It seems like something we need "from time to time" and so it might make sense to just let this be accepted with any upgrade.
Contributor
There was a problem hiding this comment.
Just realized that this is outside of the version specific if-block, so it is accepted with any upgrade. Resolving this thread.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps
OPContractsManagerV2from7.2.3to8.0.0.OPCM does not follow the normal contract semver rules. Per
book/src/policies/versioning.md— and restated in the doc comment onversion()itself — a major bump marks a new required sequential upgrade, a minor bump marks a replacement OPCM for the same upgrade, and patch bumps are ordinary development churn. U19 shipped OPCM7.xwithop-contracts/v7.0.0; U20 is the next sequential upgrade, so OPCM needs to land on8.0.0before the release is tagged.This also settles the release version.
versioning.mdderives the monorepo release from "the highest version bump of any individual contract in the release", so an OPCM major makes U20op-contracts/v8.0.0. That is consistent with the other majors already ondevelop(SuperPermissionedDisputeGame0.7.0 → 1.0.0,ProtocolVersionsremoved) and withSystemConfig3.14.2 → 4.0.0 in #21641.Doing this as its own PR so the version bump is not buried in a behavioural change, and so the RC can be cut as soon as the remaining U20 PRs land.
Testing
just snapshotsregenerated the lock; the only change isOPContractsManagerV2'sinitCodeHashandsourceCodeHash. The ABI and storage-layout snapshots are unchanged, since"7.2.3"and"8.0.0"are both 5-byte strings and nothing else moved.just snapshots-check-no-buildis clean on re-run.just test --match-contract OPContractsManagerpasses: 98 passed, 0 failed, 47 skipped. Nothing in the repo hardcodes the old7.2.3string.Note on merge order
#21641 and #22034 both bump OPCM to
7.2.4, so whichever of the three lands last needs a trivial rebase onto8.0.0. Worth landing this one last for that reason.