Create erc (minimal xERC20) #961
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Minimal interface of Sovereign Bridged Token (minimal xERC20)
File
|
bomanaps
reviewed
Mar 12, 2025
erc-xxxx.md
Outdated
|
|
||
| ## Motivation | ||
|
|
||
| With the rapid proliferation of L2s, fungible token liquidity has become increasingly fragmented across domains. What issuers really need is for a single "canonical" representation of their token to exist on each L2, regardless of which bridges are supported by the issuer. Currently, the "canonical" token of an L2 is dictated by the token issuer and is sometimes, but not always, the token minted by a given domain’s enshrined bridge - e.g. a rollup bridge. Other representations of that token can exist on the same L2 because other bridges will deploy their own flavor of the token that they can then mint/burn. In this paradigm, multiple bridges lock token liquidity on L1 (or the home domain) and mint different representations of the token on L2 (or the remote domain). This ultimately causes slippage in cross-chain token transfers because users realistically only want to use the "canonical" version. |
There was a problem hiding this comment.
Suggested change
| With the rapid proliferation of L2s, fungible token liquidity has become increasingly fragmented across domains. What issuers really need is for a single "canonical" representation of their token to exist on each L2, regardless of which bridges are supported by the issuer. Currently, the "canonical" token of an L2 is dictated by the token issuer and is sometimes, but not always, the token minted by a given domain’s enshrined bridge - e.g. a rollup bridge. Other representations of that token can exist on the same L2 because other bridges will deploy their own flavor of the token that they can then mint/burn. In this paradigm, multiple bridges lock token liquidity on L1 (or the home domain) and mint different representations of the token on L2 (or the remote domain). This ultimately causes slippage in cross-chain token transfers because users realistically only want to use the "canonical" version. | |
| With the rapid proliferation of L2s, fungible token liquidity has become increasingly fragmented across domains. What issuers really need is for a single "canonical" representation of their token to exist on each L2, regardless of which bridges are supported by the issuer. Currently, the "canonical" token of an L2 is dictated by the token issuer and is sometimes, but not always, the token minted by a given domain’s enshrined bridge - e.g. a rollup bridge. Other representations of that token can exist on the same L2 because other bridges will deploy their own versions of the token that they can then mint/burn. In this paradigm, multiple bridges lock token liquidity on L1 (or the home domain) and mint different representations of the token on L2 (or the remote domain). This ultimately causes slippage in cross-chain token transfers because users realistically only want to use the "canonical" version. |
erc-xxxx.md
Outdated
|
|
||
| However, even if bridges were all allowed to mint the same representation tokens on a remote domain, there is still an issue. On the home domain, token liquidity is locked and custodied across multiple bridges. To illustrate this problem, consider an example where two bridges control minting rights of canonical USDT on an L2: | ||
|
|
||
| - Alice bridges 100 USDT from L1→L2 through Bridge 1. The underlying L1 USDT tokens is locked in Bridge 1 and 100 USDT is minted on L2. |
There was a problem hiding this comment.
Suggested change
| - Alice bridges 100 USDT from L1→L2 through Bridge 1. The underlying L1 USDT tokens is locked in Bridge 1 and 100 USDT is minted on L2. | |
| - Alice bridges 100 USDT from L1→L2 through Bridge 1. The underlying L1 USDT tokens are locked in Bridge 1 and 100 USDT is minted on L2. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minimal interface of Sovereign Bridged Token (minimal xERC20)