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

Solve xERC20.png image path and some new line issues #1

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 14 additions & 10 deletions EIPS/eip-7281.md
Original file line number Diff line number Diff line change
Expand Up @@ -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: <URL> (TODO)
discussions-to: https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979
status: Draft
type: Standards Track
category: ERC
Expand Down Expand Up @@ -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
*
Expand All @@ -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;
Expand Down Expand Up @@ -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`
Expand All @@ -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
*/
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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:

Expand All @@ -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.
Expand Down Expand Up @@ -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.

Expand Down