user stories / features for interop ERC20

[jakim929]

Context

the goal is to outline the user stories / initial features so we can start building, and also continue to ideate on new features.

for context on the contracts / interfaces, see overview of interop ERC20 support.

Would really appreciate any comments on any other features we can add to improve devx!

User stories

1. I (token issuer) have an L1 ERC20 but not a corresponding L2 token yet, and I want to create a bridged version that uses SuperchainERC20

Flows to test

1. Use the OptimismSuperchainERC20Factory to create the OptimismSuperchainERC20 contract on multiple L2s
2. Use the OptimismMintableERC20Factory to create the OptimismMintableERC20 contract on multiple L2s
3. Use the L1StandardBridge to test bridging from L1 to L2 using the OptimismMintableERC20
4. test converting between OptimismMintableERC20 <> OptimismSuperchainERC20 using the convert function on L2StandardBridge
5. Test sending the newly created OptimismSuperchainERC20 between L2s using sendERC20 , relayERC20

2. I (token issuer) have an L1 ERC20 and an corresponding OptimismMintableERC20, and I want to upgrade it to the SuperchainERC20 (P0)

Flows to test

1. Use the factory to create the SuperchainERC20 contract on multiple L2s
2. Use the L1StandardBridge to test bridging from L1 to L2
3. Test sending the newly created SuperchainERC20 between L2s using sendERC20 , relayERC20
4. Test the convert flow on the L2StandardBridge contract to swap between legacy and SuperchainERC20 tokens

3. I (token issuer) have an L2 ERC20 on a specific L2, and I want to make it an SuperchainERC20

see https://www.notion.so/defi-wonderland/Extending-SuperchainERC20-to-L2-native-tokens-and-custom-e91ca08dd3eb4434834bf74f56237abf

Unclear what the "suggested" path here is. Some options are

1. Create a separate SuperchainERC20 "wrapper" contract that allows you to convert your existing ERC20 1:1 for the SuperchainERC20 version
2. If contract is upgradeable, some upgrade path into supporting the SuperchainERC20 contract on the base chain, for all other chains, a vanilla SuperchainERC20 might work

4. I (token issuer) don't have an ERC20, and want to create a L2 native SuperchainERC20

see https://www.notion.so/defi-wonderland/Extending-SuperchainERC20-to-L2-native-tokens-and-custom-e91ca08dd3eb4434834bf74f56237abf

Flows to test

1. Deploy a template SuperchainERC20 token on multiple L2s
2. Test sending the newly created SuperchainERC20 between L2s using sendERC20 , relayERC20

5. I (app builder) want my smart contract to be able to send / receive SuperchainERC20

Examples:

1. cross-chain DEX
2. intent solver / relayer implementation that rebalances using SuperchainERC20

Flows to test

1. Deploy any SuperchainERC20 on multiple L2s to test with, and mint initial liquidity
2. Deploy smart contract (ie. a DEX contract) that uses the SuperchainERC20
3. Test sending the newly created SuperchainERC20 between L2s using sendERC20 , relayERC20

6. I (bridge builder) want my L2 <> L2 bridge app to be able to send / receive SuperchainERC20

7. TODO: OP - delegate, voting across chains

8. TODO: maybe for wallet devs

9. TODO: SuperchainWETH

Notes:

• Because of liquidity issue (the L1 bridge for a specific L2 might not have enough funds to honor withdrawals, even though in the aggregate superchain there is enough liquidity), there may be some rough edges around devx
• Wrap => Bridge => Unwrap => Use flow is pretty cumbersome - see if there's any wrapper contracts we can create to improve this flow

Examples:

1. bridge providers (superbridge, brid.gg)

Flows to test

1. Deploy any SuperchainERC20 on multiple L2s to test with, and mint initial liquidity
2. Test sending the newly created SuperchainERC20 between L2s using sendERC20 , relayERC20

Considered features

MockSuperchainERC20

a pre-installed SuperchainERC20 on every L2 that devs can test their own contracts with

• has infinite mint, all dev accounts assigned an initial amount on startup
• mostly useful for app/bridge builders. for token issuers, not very useful except as reference

there's two versions of this

• Mock L2 native ERC20 MockL2NativeSuperchainERC20
  • simplest reference implementation for SuperchainERC20 standard
  • will serve as stop gap until the L1 bridge ERC20 contracts (factory, standard token) are finalized, or when a standard implementation for a L2 native SuperchainERC20 is introduced
  • adds a function mintTo(address) to minting by devs
• Mock L1 bridged ERC20 MockL1BridgedSuperchainERC20
  • create an L1 ERC20 contract MockL1ERC20
  • deploy the L2 bridged versions using the SuperchainERC20 factory
  • additional faucet contract that makes it easy to mint on L1 then bridge to L2

Since the factory / standard token implementation isn't ready, we can start with the L2 native mock token

Highlighted logs for ERC20 events

helps with sanity checking as devs deploy and test SuperchainERC20 tokens. this will be useful for all devs.

events to highlight

• SuperchainERC20

  • Send / Relay events

• L2StandardBridge

  • converted events for converting between legacy <> SuperchainERC20 tokens
  • New tokens minted/burned

• SuperchainERC20Factory

  • New SuperchainERC20 deployed

we'll need some way to configure / auto-index new SuperchainERC20s that are created

CLI tools for interop ERC20 contracts on supersim

• multichain deployment is a hassle. some way to let devs easily deploy contracts across multiple L2s using the dev accounts available
• also lets users send
• supersim deploy --all MyContract.sol
• supersim deploy-superchain-erc20 --all $L1ContractAddress
  • uses SuperchainERC20Factory
• adding a set of CLI commands that interact with an already running supersim sounds useful, but we should spec it out separately to see what the highest impact commands are
• rn, supersim binary is primarily for running the chains, we should consider whether we want a separate binary that function similarly to cast
  • Italiano had a spec for something like this a while back https://www.notion.so/oplabs/Draft-Super-CLI-f13bf9c160314e26921c31490b11592f?pvs=4

UI for multichain superchainERC20 deployments / management

TODO

DevConsole updates

TODO

Sequencing

• we're blocked by the implementation of the contracts in the monorepo (since the PRs are still at design or review stage). to build incrementally, I suggest

1. the MockL2NativeSuperchainERC20
2. highlighted indexing + logging for the MockL2NativeSuperchainERC20
3. when the contracts are ready, add support for the MockL1BridgedSuperchainERC20
4. highlighted indexing + logging for the L2StandardBridge, SuperchainERC20Factory, and auto index new SuperchainERC20 that were created using the factory
5. (consider) CLI tools

Notes

• The feature set is a bit weak in supporting token issuers , even though they are the P0 use case right now. We should start reaching out to them to see if we there's any tooling we can add to improve devx
• notes from sync
  • two most important use cases: ETH, OP - anchoring on these two initially
  • future-compatible SuperchainERC20 - we can start letting people deploying these ASAP

[K-Ho]

This is amazing - I think to be even more specific, for each of these i see two personas of:

1. tokens that wish to add custom functionality extending upon the SuperchainERC20 standard
2. Tokens that wish to simply use a vanilla superchainERC20 token with basic functionality

Also I think I would split out:

• Interoperable ETH
• Interoperable GovernanceToken (there's likely devx stuff around this to make cross-chain delegating/voting work)
• Real world assets (USDC, USDT, etc) - these tokens prefer to use their native mint/burn rather than Superchain interop

I'm working on some deeper research + a writeup here, but from initial metrics gathering, it's looking pretty clear that Interoperable ETH and the Interoperable GovernanceToken will be the two highest leverage projects to focus on.

ETH currently accounts for around ~50% of the third party bridge volume flowing in and out of the superchain, and USDC is the second most bridged asset for the other ~40%, but will likely end up leaning more on CCTP than the interop protocol. I don't expect ETH's share of bridge volume to change much as we enable interoperability of more long tail assets.

Hard to measure exactly how much volume we will get making OP interoperable, but its clear from talking to chain operators that having Retro funding and grants go directly to builders on other chains will be a huge value prop.

[fainashalts]

Thanks @K-Ho! I was recently talking to @mayanksayshi re: spinning up a design of how something like Superfluid could look with interop. Would be pretty cool synergy around this use case!

[mayanksayshi]

@fainashalts @K-Ho I have created a Lofi wireframe design for Superfluid with Interop in mind :)

https://www.figma.com/design/abkOIObdweA9FU8yYanLm4/Interop-Playground?node-id=1772-3900&t=bnho19a1PZ8yaiAF-4