Interop: Migrated Liquidity Storage Upgrade

[tynes]

The interop upgrade introduces a way to convert OptimismMintableERC20 tokens into SuperchainERC20 tokens that are portable and fungible across the superchain. The key to enabling this is a new storage slot introduced into the OptimismMintableERC20Factory. This storage slot is used to authenticate bytecode as "trusted" - we know that it doesn't have a backdoor in it, so we can trust it when converting to the OptimismSuperchainERC20 token.

Ideally we can role out the update to the OptimismMintableERC20Factory as part of holocene so that the mapping begins to be updated with deployed tokens. We will need to backport the tokens that were deployed before this update into storage as a one time upgrade across all of the interop chains, otherwise they will need to withdraw and re-deposit to be able to convert their tokens to the interoperable form.

This looks like a one time state surgery where the canonical list of storage entries for each chain is computed offchain. We atomically upgrade the predeploy to the StorageSetter contract and then backfill the storage slots and then upgrade back to the implementation of the factory.

[tynes]

This could be good as an individual repository that contains some scripts that build the data (set of storage slots) for each chain that need to be set. The L2 ProxyAdmin owner will be responsible for performing the upgrade, on OP Mainnet this is the aliased L1 governance multisig. All chains will need to be owned by the L1 governance multisig to be part of interop to guarantee that they do not run, so no need for extra tooling. Doing multisig upgrades goes through the superchain-ops process, to ensure that we do the upgrade correctly.

We can compute the mapping storage slots given the sentinel slot and the storage key. We did a lot of this work in Go historically for the bedrock migration. Really any language is fine to generate this, we probably want a JSON file that contains all of the slots that we can audit/perform security analysis on.

Ideally this is complete when we have a task written in superchain-ops that performs the upgrade. The msup tool by Clabby is great for making the JSON files required for the tasks.

We will want to grab all of the events for contracts being deployed through the factory. There are some additional edge cases:

• for OP Mainnet, some tokens are from before bedrock or if they are very old then they are from the regenesis. If they are before regenesis, we may need to do some archeology since the events are not available. We can compare against the token list. We can compute CREATE addresses and see if they are in the token list or see if addresses in the token list match the specific bytecode of the OptimismMintableERC20
• For Base, some tokens are deployed from a non standard deployer. This was because the legacy factory used CREATE and they did not want to have colliding addresses between different assets on two different chains. We will want to grandfather in this tokens, meaning even though they were deployed using a different factory, we will want to

[tynes]

This has been descoped for now