From 55d8914305a88812884ac9f4a932cb2b1132b4e0 Mon Sep 17 00:00:00 2001 From: Chompakorn CChaichot Date: Sun, 1 Oct 2023 17:49:58 +0700 Subject: [PATCH 1/2] fix asset file and folder names --- .../fragmentation.png | Bin .../xERC20.png => eip-7281/xERC-20.png} | Bin 2 files changed, 0 insertions(+), 0 deletions(-) rename assets/{eip-draft_bridged_tokens => eip-7281}/fragmentation.png (100%) rename assets/{eip-draft_bridged_tokens/xERC20.png => eip-7281/xERC-20.png} (100%) diff --git a/assets/eip-draft_bridged_tokens/fragmentation.png b/assets/eip-7281/fragmentation.png similarity index 100% rename from assets/eip-draft_bridged_tokens/fragmentation.png rename to assets/eip-7281/fragmentation.png diff --git a/assets/eip-draft_bridged_tokens/xERC20.png b/assets/eip-7281/xERC-20.png similarity index 100% rename from assets/eip-draft_bridged_tokens/xERC20.png rename to assets/eip-7281/xERC-20.png From db0b543a63d469c8f58b1af0eaf73061a7f1ad9e Mon Sep 17 00:00:00 2001 From: Chompakorn CChaichot Date: Sun, 1 Oct 2023 17:50:48 +0700 Subject: [PATCH 2/2] fix image paths and add some additional new lines --- EIPS/eip-7281.md | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-7281.md b/EIPS/eip-7281.md index f1d0bbbcfb02da..470632f2a61bf5 100644 --- a/EIPS/eip-7281.md +++ b/EIPS/eip-7281.md @@ -3,7 +3,7 @@ eip: 7281 title: Sovereign Bridged Token description: An interface for creating fungible representations of tokens bridged across domains. author: Shaito (@0xShaito), Excalibor (@excaliborr), Arjun Bhuptani (@arjunbhuptani) -discussions-to: (TODO) +discussions-to: https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979 status: Draft type: Standards Track category: ERC @@ -48,12 +48,12 @@ The system proposed below has two main components: ### Token Interface -All xERC-20 tokens MUST implement the standard ERC-20 interface. Note that while many of the below functions are inspired by ERC777, implementers are NOT REQUIRED to adhere to the full ERC777 specification. +All xERC-20 tokens MUST implement the standard ERC-20 interface. Note that while many of the below functions are inspired by ERC-777, implementers are NOT REQUIRED to adhere to the full ERC-777 specification. All EIP-XX tokens MUST implement the following interface. ```ts -interface IXERC-20 { +interface IXERC20 { /** * @notice Emits when a lockbox is set * @@ -76,7 +76,7 @@ interface IXERC-20 { * @notice Reverts when a user with too low of a limit tries to call mint/burn */ - error IXERC-20_NotHighEnoughLimits(); + error IXERC20_NotHighEnoughLimits(); struct Bridge { BridgeParameters minterParams; @@ -163,6 +163,7 @@ interface IXERC-20 { ``` Implementations MUST additionally satisfy the following requirements: + - `mint` MUST check that the caller's current available `limit` is greater than or equal to `_amount` - `mint` MUST increase the supply of the underlying ERC-20 by `_amount` and reduce the current available `limit` - `burn` MUST check that the caller's current available `limit` is greater than or equal to `_amount` @@ -173,7 +174,7 @@ Implementations MUST additionally satisfy the following requirements: The lockbox tries to emulate the WETH contract interface as much as possible. Lockboxes MUST implement the following interface: ```ts -interface IXERC-20Lockbox { +interface IXERC20Lockbox { /** * @notice Emitted when tokens are deposited into the lockbox */ @@ -190,19 +191,19 @@ interface IXERC-20Lockbox { * @notice Reverts when a user tries to deposit native tokens on a non-native lockbox */ - error IXERC-20Lockbox_NotNative(); + error IXERC20Lockbox_NotNative(); /** * @notice Reverts when a user tries to deposit non-native tokens on a native lockbox */ - error IXERC-20Lockbox_Native(); + error IXERC20Lockbox_Native(); /** * @notice Reverts when a user tries to withdraw and the call fails */ - error IXERC-20Lockbox_WithdrawFailed(); + error IXERC20Lockbox_WithdrawFailed(); /** * @notice Deposit ERC-20 tokens into the lockbox @@ -223,6 +224,7 @@ interface IXERC-20Lockbox { ``` Lockboxes SHOULD additionally implement the following alternative `deposit` function for native (non-ERC-20) assets. + ```ts /** * @notice Deposit native assets (e.g. ETH) into the lockbox @@ -245,7 +247,7 @@ The proposed standard attempts to satisfy the following conditions for bridged t The core problem that this standard tackles is the **fungibility** of tokens bridged across domains against the “canonical” token on that domain. (Note: which token is “canonical” 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). -![](../assets/eip-draft_bridged_tokens/fragmentation.png) +![](../assets/eip-7281/fragmentation.png) It is not enough to simply allow multiple bridges to mint the same representation on a remote domain if liquidity is locked into bridges on the home domain. To illustrate this, consider an example where two bridges control minting rights of canonical USDT on an L2: @@ -260,7 +262,7 @@ The core property that this example illustrates is that locking tokens across mu This proposal specifically solves for the above problem in cases where tokens do not already have a mint/burn interface. Tokens on the source chain are locked into a Lockbox, which mints corresponding xERC-20-compatible tokens that can be sent to bridges. -![](../assets/eip-draft_bridged_tokens/xERC-20.png) +![](../assets/eip-7281/xERC-20.png) 1. A given ERC-20 is wrapped into its xERC-20 representation. 2. The xERC-20 can then be transferred to any approved bridge. The bridge should check rate limits for the token and then `burn` the token. @@ -290,9 +292,11 @@ Regardless of the above, the failure modes associated with rate limits generally 2. In the limit-based approach, the bridge will similarly not be able to complete the transaction on the destination domain until it has more capacity available. However, a limit approach provides some more reasonable guarantees to the user: (1) user have a much higher degree of predictability around time and pricing of the outputted transaction, (2) users would not receive some wrapped representation, and (3) bridges would have a simpler pathway for users to send the tokens back to the source domain or any other destination. ### Aggregation + EIP-7281 introduces new dynamics for aggregators that massively improve user safety and experience across chains. There are two unsolved mechanism design problems that currently exist around bridge aggregation: + 1. Bridge aggregators primarily compare bridges based on price, which itself is a function of the gas costs needed to use a given bridge and the slippage due to liquidity on that bridge. Competing solely on price heavily favors (a) bridges that take a more custodial/centralized approach to cut costs, and (b) bridges that are willing and able to spend lots of capital on liquidity incentives. This creates a system of incentives that penalizes security-minded approaches & open competition. 2. Bridge aggregators tap into liquidity from DEX aggregators at the source and destination chains. To do this effectively, they need to query DEX aggregators to get a quote for a destination chain swap, *before they initiate the transaction on the source chain*. However, because liquidity-based bridges introduce slippage on crosschain transfers, there is no way for bridge aggregators to know *up front* how many tokens would be received on the destination. Aggregators currently get around this problem by defaulting to some maximum slippage (or minimum amount received) passed into the underlying bridge protocol - this means that users *always* lose 1%-3% of their value when bridging regardless of how much liquidity is available on a bridge.