design-doc: liquidity migration

[0xParticle]

Description
Added a design doc file discussing the possible approaches for the liquidity migration process for tokens locked in L1, deployed through the current and legacy OptimismMintableERC20 Factories in L2 (also known as legacy tokens), to make them fungible and compatible with Superchain interoperability.

[tynes]

Can you include the pseudocode that you were working on for how the mirror token would work?

edit: ok i see that there is going to be a follow up doc for the mirror token itself

[0xParticle]

Can you include the pseudocode that you were working on for how the mirror token would work?

edit: ok i see that there is going to be a follow up doc for the mirror token itself

I just submitted a new PR with the pseudocode:
#36

We decided to split this into two design docs because we wanted to keep discussions separated, but we can merge them if you think that would make things more clear :)

[smartcontracts]

Does anyone have concrete data on the following things:

• TVL of immutable bridged tokens created with the OptimismMintableERC20Factory
• TVL of native L2 tokens
• TVL of bridged tokens that are upgradeable

This would be highly valuable IMO.

[zainbacchus]

TVL of bridged tokens that are upgradeable:
TVL of immutable bridged tokens created with the OptimismMintableERC20Factory:
TVL of native L2 tokens: https://l2beat.com/scaling/projects/optimism/tvl-breakdown
TVL of L1StandardBridge: https://etherscan.io/address/0x99C9fc46f92E8a1c0deC1b1747d010903E884bE1#multichain-portfolio

[MSilb7]

One metapoint: Want to clarify when we mean TVL versus Assets Onchain

The L2Beat and Etherscan links to do show assets on chain, I can work on app TVL (assuming these are the assets that will actually move vs being stuck in CEXs / wallets) -> Can likely show the breakdown of each.

---

Second, is the bridged tokens that are upgradeable / immutable bridged tokens distinction just if they're behind a proxy?

--

I also imagine we're talking about as many Superchain members as we can get, not just OP Mainnet right?

[zainbacchus]

@MSilb7 context of the question is: how much of assets bridged are upgradable / non-upgradable. If majority is non-upgradable then we need to prioritize mirroring, if its upgradable we might not need to pri mirroring for the initial release.

We care about assets on chain.

Re members - starting with Base, OPM would be great as that's the majority of liquidity to inform the above.

Proxy would work to determine upgradable!

[MSilb7]

Ok yeah, if you all have a good way to identify which tokens are proxies vs not, you can match that up against L2Beat.

I know USDC is a proxy as an example. We could ~try to approximate it like "did the token ever emit an upgrade event."

[MSilb7]

What contract(s) are the OptimismMintableERC20Factory?

I was looking at 0x4200000000000000000000000000000000000012 on OPM and Base, but I'm seeing some tokens on L2Beat that were minted on Base via 0xf23d369d7471bD9f6487E198723eEa023389f1d4. Are the custom ERC20 factories, or are these custom ones not valid?

[MSilb7]

per Base docs, seems like this is another token factory 0xF10122D428B4bc8A9d050D06a2037259b4c4B83B

If chains are rolling their own token factories, we'll likely need a registry of this.

[MSilb7]

Assuming the Custom ERC20 factories are legitimate
https://github.com/ethereum-optimism/op-analytics/blob/main/misc_analysis/get_aoc_by_token_type.ipynb

Looked at Assets Onchain for Base and OPM

• Proxy Tokens, Non-Proxy, Native (ETH) even about 25% each (~30% each excl. predeploys)
• Immutable token factory 8%
• OP (Predeploy) 14.7%

[Sheet Link](https://docs.google.com/spreadsheets/d/1U-2RpZGJDgPz5Lig_EUROaUJFKR1n2ocLockPXugq6A/edit?gid=1988079523#gid=1988079523)

• Base rolled custom minting factories.
• Assets Onchain value sourced from L2Beat & Mapped to the L2 token address.
• Tokens created on OP Mainnet pre-regenesis were labeled as "Unknown," unless a proxy event was observed post-regenesis.
• Tokens without an onchain L2<>L1 mapping were also marked as unknown.

Data Issues:

• Some L1 tokens map to multiple L2 tokens by bridge events. In this case, we used amount of dex swaps as the indicator for which version of the token to treat as the adopted version.
• The immutable token factory events seem to be spoofable, which will cause token classification errors, if you go off of factory events (i.e. Native USDC appears to be factory created, when it is not). I manually overrode USDC, but there may be other bugs.
• ^ Request: Can we make sure there's no ability for people to spoof token creations like this going forward?

[mds1]

So this is basically a double entry point (DEP) token, where a user can interact with a token either from it's existing OptimismMintableERC20 contract OR from the new MirrorERC20 contract? If so my initial reaction is that this design makes me very nervous—DEP tokens have been the cause of at least two security vulnerabilities:

• Compound issue: 1, 2
• Balancer issue: 1, 2

I suspect part of the reason there are "only" two instances of vulnerabilities from DEP tokens is because there aren't many DEP tokens that protocols integrate with. Now we are making every bridged token a DEP token—how many protocols would this introduce vulnerabilities for?

It's also possible I have misunderstood, and that there's something unique about this design that gives us confidence we are not introducing any vulnerabilities?