-
Notifications
You must be signed in to change notification settings - Fork 36
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
Conversation
Co-authored-by: ng <[email protected]> Co-authored-by: Joxes <[email protected]>
There was a problem hiding this 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). |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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`. |
There was a problem hiding this comment.
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?
We decided to go with the approach in #46, so closing this |
Description
This document presents a solution for migrating
OptimismMintableERC20
, which corresponds to locked liquidity in L1, to theSuperchainERC20
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 theOptimismMintableERC20
and the correspondingSuperchainERC20
.