[Application Development] Interfaces for bridging L1 and L2 tokens

[matjazv]

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

Hello everyone!

Suppose we are creating a new chain using the OP Stack. We aim to create a new ERC-20 bridged token on the L2 side. We will utilize the following contract as our foundation: https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/universal/OptimismMintableERC20.sol

Some questions:

1. Do we need to incorporate all the legacy functions and interfaces? If not, would it still be advisable to include them? (We are apprehensive that some prominent centralized and decentralized exchanges might still be reliant on the old interface.)

2. Does L1 token also need to inherit IOptimismMintableERC20 interface? Our concern is that some UX could "break" because it sees the token has this interface on the L2 and then assumes it has the same interface on the L1.

3. Is it safe (and future proof) to implement IOptimismMintableERC20 interface on L2 token and not on L1 token?

Additional Information

No response

Feedback

No response

[sbvegan]

Let me work on finding the answer for you. In the meantime here's some docs:

• https://docs.optimism.io/builders/dapp-developers/bridging/basics
• https://docs.optimism.io/builders/dapp-developers/tutorials/standard-bridge-standard-token

[Chomtana]

Disclaimer: I'm not 100% sure on this

Do we need to incorporate all the legacy functions and interfaces? If not, would it still be advisable to include them? (We are apprehensive that some prominent centralized and decentralized exchanges might still be reliant on the old interface.)

I think it's safer to include them for L2 token in case some interface still use them

Does L1 token also need to inherit IOptimismMintableERC20 interface? Our concern is that some UX could "break" because it sees the token has this interface on the L2 and then assumes it has the same interface on the L1.

I think IOptimismMintableERC20 only needs to be implemented on the destination chain which is L2 in your case.

Is it safe (and future proof) to implement IOptimismMintableERC20 interface on L2 token and not on L1 token?

Yes, as IOptimismMintableERC20 only needs to be implemented on the destination chain which is L2 in your case.

Reason behind this

• For L1 -> L2: Implement IOptimismMintableERC20 on L2 because it lock real token on L1 and mint wrapped token on L2
• For L2 -> L1: Implement IOptimismMintableERC20 on L1 because it lock real token on L2 and mint wrapped token on L1

[github-actions[bot]]

Hey @matjazv, We hope your recent question was resolved to your satisfaction. Your feedback is invaluable and helps us improve our support services. Could you spare a moment to fill out a short feedback survey. Thank you for helping us improve our developer community.