feat: crosschain ERC20 (ERC-7802 and ERC-7281) #203
Conversation
hexshire
changed the title
protocol/crosschain-erc20.md
Outdated
| 2. Deploy a Lockbox contract that: | ||
| - Locks the original ERC20 tokens | ||
| - Mints CrosschainERC20 tokens at a 1:1 ratio | ||
| - Can be deployed deterministically to have the same address across all chains |
There was a problem hiding this comment.
To clarify, the minted CrosschainERC20 would have a deterministic address across all chains right? Not the Lockbox. The Lockbox would only exist on the hub chain where the token was originally deployed
There was a problem hiding this comment.
Zain, you are right on this one. Fixed on 9673db8
There was a problem hiding this comment.
What if the non xERC20 token was already bridged to another chain by a different bridging method? Would you then need the Lockbox on both chains, not just the hub chain?
There was a problem hiding this comment.
Ideally, the Lockbox should be on a single chain or hub chain to avoid liquidity issues with the Lockbox. If there are different methods to bridge the tokens, this could cause a situation where, on a given chain, there are not enough funds in the Lockbox to unlock the original ERC20. In this case, the funds should be returned using the bridge initially used and locked in the hub chain.
protocol/crosschain-erc20.md
Outdated
|
|
||
| Key benefits: | ||
|
|
||
| - The most simple/straightforward solution, token do not need to have the same address. |
There was a problem hiding this comment.
How can the token not have the same address if it stills using SuperchainTokenBridge?
There was a problem hiding this comment.
In this case, the SuperchainTokenBridge is going to call the Adapter (then the Adapter calls the xERC20 mint/burn) and not the token directly. So, we need to be sure the adapter has the same address on every chain. I added more details on this section description. 9673db8
|
Thanks! Dropped some questions on Option C but otherwise LGTM. Strong agree this should not be a predeploy but available similar to the work done for opUSDC: https://github.com/defi-wonderland/opUSDC |
|
|
||
| For tokens already deployed as non-upgradable `xERC20`, upgrading to implement ERC-7802 is not an option. To integrate with the Superchain while maintaining existing bridge infrastructure, an `ERC7802Adapter` can be used. This contract implements `ERC-7802`’s crosschainBurn and crosschainMint functions, translating them into the corresponding `xERC20` mint/burn operations. | ||
|
|
||
| Since bridges will interact with the adapter instead of the token contract, the adapter must be deployed deterministically to ensure the same address across all chains. |
There was a problem hiding this comment.
So tokens do not need to be deterministically deployed with the adaptor? How is the total supply of a token across all the chains calculated? Does this make it harder?
There was a problem hiding this comment.
if the xerc20 contract is passed into the constructor of the adaptor, wouldn't the xerc20 address still need to be the same across all chains in order for the adaptor address to be the same across all chains?
There was a problem hiding this comment.
oh I see the factory uses CREATE3 so constructor params won't matter
There was a problem hiding this comment.
So tokens do not need to be deterministically deployed with the adaptor? How is the total supply of a token across all the chains calculated? Does this make it harder?
In this case, the bridge (or SuperchainTokenBridge) calls the Adapter and it calls the Token contract, the Adapter does not hold any token. For this reason, it is not necessary for the Tokens to have the same address, but the Adapters must.
To calculate liquidity: If the tokens have the same address across all chains, the usual methods would be used. However, if the tokens do not have the same address, the variable in the adapter that stores the adapted token's address could be used to redirect the calculation.
| For tokens that are already deployed and cannot be upgraded, use a Lockbox mechanism: | ||
|
|
||
| 1. Deploy a `CrosschainERC20` contract that will be the wrapped version of the original token | ||
| 2. Deploy a `Lockbox` contract that: |
There was a problem hiding this comment.
same with the adaptor? one adaptor per xerc20 per chain?
There was a problem hiding this comment.
It is one lockbox per token, but on the adapter side, one adapter is deployed per bridge per token. The purpose of having one adapter per bridge is that limits are unique for that bridge. Having an adapter with both A and B bridges means that if bridge A is hacked, it can use the limits on both A and B.
|
|
||
| Pre-requisite: | ||
|
|
||
| - `xERC20` addresses MUST be the same in both chains |
There was a problem hiding this comment.
how common is it for xERC20 addresses to be the same?
There was a problem hiding this comment.
In this case, we are requiring as a prerequisite that the token be deployed at the same address. If this is not the case, the token issuer would need to resolve this situation, as it is outside the scope of this solution.
|
|
||
| _Worth mentioning that the Lockbox solution described in section B is also compatible with this scenario, providing an alternative option if the token issuer prefers to wrap their `xERC20` into a new `CrosschainERC20` token_ | ||
|
|
||
| ### **CrosschainERC20Converter** |
There was a problem hiding this comment.
Not sure I understand this one: so the CrosschainERC20Converter contract is a CrosschainERC20 contract? What does the undo call do?
There was a problem hiding this comment.
The CrosschainERC20Converter would be a CrosschainERC20 with an extension that allows burning xERC20 and minting CrosschainERC20 within the same contract. It is like a Lockbox, but instead of locking, it burns the xERC20. The undo function would be the inverse of convert, burning CrosschainERC20 and minting the xERC20 again.
However, is important to mention this is not the solution we are going to implement.
| 1. Within the Superchain: Uses the SuperchainTokenBridge for fast (1-block) and secure transfers | ||
| 2. Outside the Superchain: Allows configuration of any EVM-compatible third-party bridge through xERC20's mint/burn permissions | ||
|
|
||
| ## **B. Deployed, non-upgradable tokens (Non-xERC20)** |
There was a problem hiding this comment.
would this path also be taken for ERC7802 tokens that are non-upgradeable and non-xerc20?
There was a problem hiding this comment.
Using the lockbox to move from SuperchainERC20 to CrosschainERC20 is valid.
Description
This design document aims to provide a clear implementation path for token issuers who want to make their tokens interoperable across both the Superchain and other ecosystems, while maintaining compatibility with existing bridge infrastructure.
Contracts naming is open to discussion since the idea is to open these implementations to be compatible with any bridge that uses ERC-7802 or ERC-7281.