Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

design-doc: convert isolated #45

Closed
wants to merge 1 commit into from
Closed

Conversation

0xParticle
Copy link
Contributor

Description
This document presents a solution for migrating OptimismMintableERC20, which corresponds to locked liquidity in L1, to the SuperchainERC20 standard to be interop compatible.

To do that, we suggest using the L2StandardBridge mint/burn rights over the legacy representations to allow easy conversion between the OptimismMintableERC20 and the corresponding SuperchainERC20.

Co-authored-by: ng <[email protected]>
Co-authored-by: Joxes <[email protected]>
Copy link
Contributor

@protolambda protolambda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good, but I have some questions about the token-address mapping between legacy and super.

return superFactory.deployment(_legacyAddr) == _superAddr;
}
```
- **Deterministic address**: The `SuperchainERC20` factory will use the L2 representation address as a salt, so the address of the `SuperchainERC20` can be deduced from the address of the `OptimismMintableERC20` and the Factory (predeploy).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any L2 chains with conflicting tokens at the same address, minted by the system factory? I remember Base running into something like this with a previous factory. If yes, then that breaks the deterministic-address assumption. Using the L1-address of the token may be more safe (if that can be authenticated to be correct).


- **Check `OptimismMintableERC20` address is valid**: there is no need to verify anything as any liquidity risk will be isolated.
- **Check `SuperchainERC20` is valid**: There are two ways to implement access control in the Isolated design.
- **Registry**: If the Factory stores the `SuperchainERC20` address for each legacy address.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the factory choose to store an L2 super-erc20 contract address value by a _legacyAddr L2-address key? Does it store it upon deployment of the erc20? What happens to previously deployed addresses?


The Convert Method will require modifying the `L2StandardBridge` to include the following:

- `convertToSuper(address _*legacyAddr, address _superAddr, uint256 _amount)`: converts* `_amount` *legacy tokens with address `_*legacyAddr` to the same `_amount` of `SuperchainERC20` tokens in address `_superAddr`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sanity check: is the _legacyAddr the same across all L2 chains, for the same L1 token?

@tynes
Copy link
Contributor

tynes commented Jul 17, 2024

We decided to go with the approach in #46, so closing this

@tynes tynes closed this Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants