[Application Development] L1 -> many L2s: OptimismMintableERC20Factory <> SuperchainERC20

[elmariachi111]

Did you check the documentation?

• Yes
• No

Documentation Feedback (Optional)

I found too much stuff that's potentially contradicting and old and can be misinterpreted in several places of the docs, eg

• https://docs.optimism.io/interop/starter-kit#deploy-a-token
• https://docs.optimism.io/interop/tutorials/custom-superchain-erc20#create-a-basic-erc20-contract
• https://docs.optimism.io/interop/tutorials/deploy-superchain-erc20
• https://docs.optimism.io/interop/superchain-erc20
• https://docs.optimism.io/interop/compatible-tokens#why-use-superchain-interop-to-enable-cross-chain-token-interoperability

vs

• https://docs.optimism.io/app-developers/tutorials/bridging/standard-bridge-standard-token
• https://docs.base.org/chain/bridge-an-l1-token-to-base
• https://github.com/base/guides/tree/main/bridge/native (marked deprecated by the base team)

Hence after 3hs of investigation I decided to ask.

What type of issue are you experiencing?

• Error
• Feature Request
• General Question

Issue Description

(this is partly speculative, but mostly a real world scenario I'm facing)

• I want to bridge tokens from L1 / Mainnet -> L2 (and be able to withdraw).
• I want to profit from the latest "SuperChainERC20" features, mostly erc-7802, to profit from instant xchain transfers
• My token on L1 already exists (!)

How do I bridge that token to some L2? According to the docs this happens through the Standardbridge. https://docs.optimism.io/app-developers/bridging/standard-bridge / https://docs.base.org/chain/bridge-an-l1-token-to-base . If I'd use the suggested OptimismMIntableERC20Factory, it will clone a default bridge-mintable contract and its address will depend on the create2 params on that contract, out of my control. https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20Factory.sol#L130 . This token incarnation obviously will not be a super chain token. It even will only be bridgeable to another L2 using the same mechanics, if we need to trust L1 finality.

What I could do is to manually deploy/create2 a SuperChainERC20 contract with built in OptimismMintableERC20 features. That would allow the standard bridge minting supply on it when messaged from the L1. Is that the way to go?

Steps to Reproduce

• Deploy ERC20 on L1
• Bridge to some L2
• Wonder how to make this as SuperchainERC20.

Are you using a specific library or SDK?

• OP-SDK
• Viem
• Other
• Not Sure

Are you using the latest version of the library/SDK?

• Yes
• No

Environment Details

No response

Troubleshooting Attempts

No response

What type of support do you need?

• Technical support for issue resolution
• Feature implementation guidance
• General advice or consultation
• Documentation or learning resources

Additional Information

I first tried building this kind of stuff in June 2023 and I created a deterministic L2 target address predictor by hackstracting the binary initcode of the mintable L2 token manually (https://gist.github.com/elmariachi111/ffba2ac241404cb80ed06b39cc24e334) which helps us to get rid of the fully centralized git token list 🙈

Feedback

Think the docs (particularly the x-chain / x-ecosystem ones) must be streamlined. Even though it's not your business, tell the base team to at least give a reason why they deprecate official sample repos.

[joohhnnn]

Before I can properly answer your question, let me clarify a few things. Currently, there are two types of cross-chain message passing: the standard message passing and the interop message passing.

The main difference is how they handle delays and trust assumptions. With the standard method, messages from the mainnet to an L2 are processed immediately without a challenge period. However, messages from an L2 to another L2, or from an L2 back to mainnet, require a longer challenge period—typically 7 days.

Interop message passing, on the other hand, allows near-instant messaging between L2s without any challenge period. But messages from an L2 to the mainnet still require the challenge delay.

Standard bridges are used with OptimismMintableERC20, while interop bridges are used with SuperChainERC20.

Given your situation—your token is already deployed on mainnet and isn’t implemented using SuperChainERC20—I don’t believe you’ll be able to take advantage of instant cross-chain transfers with your token.

[elmariachi111]

great and thanks for the response. But what's the point of deploying a tokens as "SuperChainERC20" on an L1? It certainly won't approve "crosschainBurn" calls on a precompile (0x4200000000000000000000000000000000000028) as.... there is no such precompile on L1 ;)

That's the essence of my question actually: Would I really deploy the origin ERC20 contract on the L1 including the "crosschain" functions, even though the contract on L1 will of course never be the target of any of these calls? Since that's quite obviously not necessary, I'm wondering what would hold me back to just create superchain erc20s and connect them all (or at least 1 of them) with the "remote" token on the l1, so users can use that contract to completely withdraw from the L2 superchain.

[jsvisa]

This contract was deployed in L2, not L1, eg

• optimism: https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000028
• base: https://basescan.org/address/0x4200000000000000000000000000000000000028