Removing superchain_time from chains not on the latest releases #986
Conversation
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
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.
Description
This PR removes the
superchain_timefrom chain configurations that are not on the latest smart contract release version and/or hardfork. I have added theF-do-not-mergelabel because I want to do comms with these chain operators prior to merging and this going into effect. They need an opportunity to assess the downstream effects of this change.Certain edge cases will be applied if the Security Council or the Optimism Foundation is part of the multisig that holds the L1 ProxyAdmin owner role. If these entities are part of your upgrade process and you're behind on L1 smart contract upgrades; we are actively working towards upgrading these chains to the latest version. We will add the superchain wide activation behavior back to your chains once we have them in sync with the Superchain whom conform to the Standard Rollup charter.
Motivation
The way we test upgrades are to do the L1 contract upgrade first and then activate the hard fork. We do not want to be activating hard forks on networks that do not have the latest L1 contract releases yet because there are potential footguns that may not have been considered because we are following the expected upgrade release process of L1 contracts then hard fork.