interop: token standard

[tynes]

Description

Initial pass

• needs general feedback on approach
• needs section on factory
• needs section on migration from existing optimism mintable erc20 tokens

[skeletor-spaceman]

another idea that might help quite a lot with interoperabolity would be to add an execute instruction after the mint. i.e. "pseudo-code example"

function bridgeERC20To(address _to, uint256 _amount, uint256 _chainId, bytes calldata _data) public {
    _burn(msg.sender, amount);

    L2ToL2CrossDomainMessenger.sendMessage({
      _destination: chainId,
      _target: address(this),
      _message: abi.encodeCall(this.finalizeBridgeERC20, (msg.sender, to, amount, _data))
    });
  }

  function finalizeBridgeERC20(address _from, address _to, uint256 _amount, bytes calldata _data) external {
    require(msg.sender == address(L2ToL2CrossChainMessenger));
    require(L2ToL2CrossChainMessenger.crossDomainMessageSender() == address(this));

    _mint(_to, _amount);
    if (_data.length > 0) to.call(_from, _amount, _data);
  }

[tynes]

another idea that might help quite a lot with interoperabolity would be to add an execute instruction after the mint. i.e. "pseudo-code example"

function bridgeERC20To(address _to, uint256 _amount, uint256 _chainId, bytes calldata _data) public {
    _burn(msg.sender, amount);

    L2ToL2CrossDomainMessenger.sendMessage({
      _destination: chainId,
      _target: address(this),
      _message: abi.encodeCall(this.finalizeBridgeERC20, (msg.sender, to, amount, _data))
    });
  }

  function finalizeBridgeERC20(address _from, address _to, uint256 _amount, bytes calldata _data) external {
    require(msg.sender == address(L2ToL2CrossChainMessenger));
    require(L2ToL2CrossChainMessenger.crossDomainMessageSender() == address(this));

    _mint(_to, _amount);
    if (_data.length > 0) to.call(_from, _amount, _data);
  }

This is definitely good feedback and something that we could include to reduce the number of transactions that users need to send

[skeletor-spaceman]

glad u liked it @tynes :)

also, how do you see these SuperchainERC20s interacting with their non-superchain counterparts? as a developer I might want to keep the canonical flavor or my SuperchainERC20 but this will force me to always enter/exit the superchain via the canonical bridge. bridges wanting to provide a fast entry/exit will be forced to wrap those assets, generating the need for a secondary liquidity market of wrapped <> canonical assets.

if I wanted to use xERC20 for this. I would only use the canonical SuperchainERC20 as an internal messaging layer which would be wrapped to the xERC20 representation via a Lockbox contract on each chain.

do you think that this standard needs to be an actual ERC20 flavor? or can it be a periphery helper with minter/burner roles into a standard ERC20 or xERC20 implementation?

I know this adds complexity to a very clean and straightforward implementation. but i wanted to know the reasoning behind the support for creating a new standard.

[pegahcarter]

From the Frax side (currently operating on a non-superchain), I have a some opinions/questions:

• It may be worth allowing superchain => non-superchain op-stack but not non-superchain op-stack => superchain. This should maintain trust assumptions within the superchain ecosystem while still providing some support for op-stack in general.
• xERC20 solves bridge liquidity but not necessarily protocol liquidity. How should a multi-superchain protocol operate? For example, lending protocols which mint their native token on each chain would be required to mint the universally bridgeable xERC20. Should the protocol contracts also have the ability to mint the xERC20?
• Where is each xERC20 first initialized? On Optimism or their native Superchain?
• Do permissions of the xERC20 change if one chain goes from superchain => non-superchain or non-superchain op-stack => superchain?

[skeletor-spaceman]

hi @pegahcarter nice qs! hope I can give you some useful answers.

Should the protocol contracts also have the ability to mint the xERC20?

100%, this is the intended use-case.

Where is each xERC20 first initialized? On Optimism or their native Superchain?

this is a great question, we are currently working on a standard for this specific issue. we'll be able to share more details soon :) also, xERC20 can be manually setup on any chain, no canonical chain is required.

Do permissions of the xERC20 change if one chain goes from superchain => non-superchain or non-superchain op-stack => superchain?

the only thing that would happen here would be that the "superchain L2<>L2 canonical bridge" will be "deprecated". if the xERC20 has no-owner, and only had that superchain minter, it will be effectively bricked to receive or send any further messages. but it can still be re-wrapped into an xERC20 Lockbox, by treating it just like a vanilla ERC20 with no minters.

[tynes]

To enable the token standard to scale, we are going to want to use a factory that uses a create3 style deployment to ensure that we don't always enforce every contract bytecode to be the same forever. We will likely want to use ERC20 specific identifying information hashed together to create the salt, perhaps with a version to make it flexible longer term. This deterministic address generation scheme would enable superchain enabled ERC20 tokens to not maintain a chain id to address mapping of the same asset on other chains.

[skeletor-spaceman]

@tynes this is a great idea! we are right in the middle of a research spike to figure out the best way to do this cross-chain. some findings and caveats we encountered so far are:

0. for no-owner ERC20s the salt should simply be, as you said, the ERC20 init params. existing tokens will have their original token address differ from the "op-stack" representation. but this should be ok, since we could use a lockbox design to bridge it :)
1. where would our single source of truth live? i.e. always deploy through L1 using the canonical bridge, or OP mainnet using the Interop bridge.
2. developing a custom create3 factory that complies with the canonical/interop bridge is required for point 1) since the salt would have to include origin chain-id and origin sender
3. an origin domain factory would enforce safe multi-chain deployments and upgrades.
4. cross-chain ownership is tricky, there are 2 distinct scenarios to take into account, the first one is if the owner is a contract/address on the origin domain, and all "onlyOwner" actions are done through the canonical/interop bridge. the second scenario, where the owner is defined and controlled per-chain, has a way higher risk profile, since 1 "evil" owner could rug the liquidity of other chains with supply of this fungible tokens. mostly on upgradeable of "owner-mintable" tokens.
5. cross-chain deployment of origin-owned contracts should be permissionless.

do these points resonate with what you were thinking?

[pegahcarter]

IMO cross-chain ownership should be delegated to the initial point of token issuance and is a requirement to this standard. If ownership is not desired, it can always be renounced.

What would a no-owner token look like on a cross-chain other than the gas token? From my understanding every protocol that would want interoperability would need to approve a non-bridge minter contract for their token. For example, Maker would want to prove some contract they deployed on different superchain for DAI minting rights.

It's tough because unless the token and protocol are deployed deterministically across chains (unless there's some other way), there's additional trust required and immutable protocols may not support the opened minting abilities.