Create erc (minimal xERC20)

erc-7905.md

@@ -0,0 +1,226 @@
+---
+eip: 7905
+title: Minimal interface of Sovereign Bridged Token (minimal xERC20)
+description: An interface for creating fungible representations of tokens bridged across domains - a core xERC20 basic interoperability standard
+author: Radek Svarz (@radeksvarz), Shaito (@0xShaito), Excalibor (@excaliborr), Arjun Bhuptani (@arjunbhuptani)
+discussions-to: https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979
+status: Draft
+type: Standards Track
+category: ERC
+created: 2025-03-07
+requires: 20, 165
+---
+
+## Abstract
+
+This proposal defines a minimal extension to [ERC-20](../EIPS/eip-20.md) (affectionately called `minimal XERC20`) that enables bridging tokens across domains without creating multiple infungible representations of the same underlying asset. It exposes new interfaces that allow fungible token issuers to apply custom risk profiles at a per bridge per domain granularity. 
+
+The related ERC-7281 (XERC20) proposal encompasses Lockbox wrappers, structs, and extensive configuration functions, exceeding the minimal requirements for core interoperability. This ERC presents a streamlined, focused approach, providing the essential functionality for 'xERC20 native' fungible token interoperability."
+
+## 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.
+
+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 are locked in Bridge 1 and 100 USDT is minted on L2.
+- Bob bridges 100 USDT from L1→L2 through Bridge 2. Similarly, the underlying L1 USDT tokens are locked in Bridge 2 and 100 USDT is minted on L2.
+- Suppose Alice pays Bob her 100 USDT on L2. Bob now has 200 USDT.
+- Bob attempts to bridge the 200 USDT from L2→L1 through Bridge 2. This transaction fails because Bridge 2 only has 100 USDT custodied that it can give to Bob.
+
+The core property that this example illustrates is that locking tokens across multiple bridges on the token’s home domain makes it impossible to have fungibility without impeding user experience on remote domains. Minting or burning the token can solve this problem, but not all [ERC-20](./eip-20.md) tokens implement a configurable mint/burn interface. 
+
+This, coupled with the need for projects to transfer tokens between chains faster than rollup exit windows, means that token issuers must choose from one of two options to bridge their tokens:
+
+1. Bridge tokens through the “canonical” rollup bridge and work with atomic swap or fast-liquidity providers for L2→L1 or L2→L2 interactions. While this is the safer option, it necessitates significant requirements for issuers to incentivize or bootstrap liquidity on every supported chain, limiting support to only the most liquid of assets. Liquidity-based bridging additionally introduces slippage or other unpredictable pricing for users, hindering composability across domains.
+2. Work with a 3rd party bridge. This option removes liquidity and pricing concerns making it more favorable for longer-tail issuers, but locks a given minted representation of a bridged token to only its associated bridge. This creates a tradeoff for issuers between security/sovereignty and user experience: If the token is bridged through only a single provider, the token supply and implementation is now fully and in perpetuity controlled by the bridge. If the token is bridged through multiple options (including "canonical" rollup bridges), multiple infungible (“wrapped”) representations of the same underlying asset are created on L2.
+
+In the ideal case, token issuers want the following properties for their bridged tokens:
+
+- Fungibility, as highlighted above.
+- Sovereignty. Issuers want to be the logical owners of the canonical representation of their token on L2 and not be locked into any single specific option forever.
+- Security. Issuers want to opt into novel secure bridging approaches as they are developed and have granular control over their risk tolerance for any given option.
+- Minimal Liquidity. Issuers want to minimize the costs and complexity of acquiring liquidity for their token on each supported bridge and chain. This property becomes increasingly important as the space eventually expands to 100s or 1000s of connected domains.
+
+There has been some previous work to solve these problems. However, solutions have historically either failed to satisfy all of the above desirable properties or have been custom-built for only a single token ecosystem.
+
+- Celer’s Open Canonical Token Standard proposed a lock-in free standard for bridging tokens to new domains. However, it largely targeted alternative L1s (that don’t already have a canonical bridge) and did not fully solve the fungibility problem. Regardless, Celer’s approach inspired some of the key thinking behind this standard.
+- Maker’s Teleport facility allows for minting and burning canonical DAI between domains. While the approach solves for the desirable properties above, it is highly custom to Maker’s architecture and relies on Maker’s own economic security to function. Circle CCTP similarly solves this problem, but using a mechanism that only centralized token issuers can implement.
+- Token issuer multi-bridge implementations, e.g. Angle protocol, Frax Ferry, and Threshold Network’s tBTC. These examples solve for some or all of the above desiderata and can be applied more broadly to all tokens if coupled with minor additions for compatibility with existing deployed tokens.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+### Overview
+
+### Token Interface for bridged tokens
+
+All `minimal XERC20` tokens MUST implement the standard `ERC20` interface.
+
+All `minimal XERC20` tokens MUST implement the following interface.
+
+```solidity
+// The EIP-165 identifier of this interface is 0xec7b9e15
+/**
+ * @notice A minimal XERC20 interface for fungible tokens and their bridge mechanisms.
+ */
+interface IERC7905 {
+    /**
+     * @notice Reverts when a bridge with too low of a limit tries to call mint/burn
+     */
+    error IXERC20_NotHighEnoughLimits();
+
+    /**
+     * @notice Returns the max limit of a minter
+     *
+     * @param _bridge The bridge we are viewing the limits of
+     * @return _limit The limit the bridge has
+     */
+    function mintingMaxLimitOf(address _bridge) external view returns (uint256 _limit);
+
+    /**
+     * @notice Returns the max limit of a bridge
+     *
+     * @param _bridge the bridge we are viewing the limits of
+     * @return _limit The limit the bridge has
+     */
+    function burningMaxLimitOf(address _bridge) external view returns (uint256 _limit);
+
+    /**
+     * @notice Returns the current limit of a minter
+     *
+     * @param _bridge The bridge we are viewing the limits of
+     * @return _limit The limit the minter has
+     */
+    function mintingCurrentLimitOf(address _bridge) external view returns (uint256 _limit);
+
+    /**
+     * @notice Returns the current limit of a bridge
+     *
+     * @param _bridge the bridge we are viewing the limits of
+     * @return _limit The limit the bridge has
+     */
+    function burningCurrentLimitOf(address _bridge) external view returns (uint256 _limit);
+
+    /**
+     * @notice Mints tokens for a user
+     * @param _user The address of the user who needs tokens minted
+     * @param _amount The amount of tokens being minted
+     */
+    function mint(address _user, uint256 _amount) external;
+
+    /**
+     * @notice Burns tokens for a user
+     * @param _user The address of the user who needs tokens burned
+     * @param _amount The amount of tokens being burned
+     */
+    function burn(address _user, uint256 _amount) external;
+}
+```
+
+Implementations MUST additionally satisfy the following requirements:
+
+- `mint` MUST check that the caller's current available minting `limit` is greater than or equal to `_amount`
+- `mint` MUST increase the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
+- `burn` MUST check that the caller's current available burning `limit` is greater than or equal to `_amount`
+- `burn` MUST decrease the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
+
+## Rationale
+
+The proposed standard attempts to satisfy the following conditions for bridged tokens regardless of where and how they are bridged:
+
+1. Tokens received at the destination should be the canonical tokens.
+2. Bridges should not need to bootstrap liquidity for each new chain and asset.
+3. Cross-domain interactions involving tokens should be slippage-free, simplifying composability.
+4. Token issuers should own decision-making around which bridges to support and be able to parametrize risk for each. They should not be locked into only supporting a single bridge.
+
+### Rate Limits
+
+A key consideration for consolidating home chain liquidity (and, by extension, allowing multiple bridges to mint the same representation) is the risk introduced due to the failure of any single bridge. In other words, there is a tradeoff space between fungibility (i.e. user experience) and security.
+
+The current best practice for limiting this risk is for issuers to enshrine a single bridge that mints the canonical representation on a given domain (this is often the rollup bridge, but we are increasingly seeing projects moving to proprietary/3rd party bridges citing liquidity and UX concerns). In this case, the token issuer fully trusts the enshrined bridge. Alternative bridges that want to support the token then must build liquidity for the token, where the risk to the token issuer of a given bridge’s failure is capped to the total liquidity locked in the bridge.
+
+The `XERC20` proposal attempts to mimic and improve upon this risk topology without the need for external liquidity. Instead of risk being capped by the locked tokens in a given (non-enshrined) bridge, risk is now capped by rate limits that are configurable on a per-bridge basis. This gives issuers granular control over their risk appetite as issuers can experiment with different bridges and adjust their confidence over time. Perhaps most importantly: this approach also encourages more open competition around security, as issuers no longer have to default to using only the most liquid or well-funded options.
+
+### Edge Case Considerations for Limits
+
+Minting and burning limits introduce failure modes that can impede UX. This is a necessary part of ensuring that bridge risk is compartmentalized and this standard assumes that implementers can work towards raising or altogether removing limits for bridges as they build confidence in them over time.
+
+Regardless of the above, the failure modes associated with rate limits generally map directly to **existing** failure modes around insufficient liquidity on bridges, and in many cases improve upon them. The two cases to consider here are:
+
+1. Hitting burn limits on the source chain. This case is hit when a given bridge has capped its limit on burning tokens, causing a revert of the transaction that included a call to the bridge. 
+    1. In the current liquidity-bridging model, bridges will typically have no way to know upfront if they have sufficient liquidity on the target chain for a given transaction. This means that a limit-based approach (where the transaction **fails fast**) is a significant improvement to UX.
+2. Hitting minting limits on the destination chain. This case can be hit *after* tokens are burned on the source chain in cases where many different minting transactions are simultaneously triggered on a given destination domain and bridge combination, leading to the bridge’s limit being saturated.
+    1. This problem exists in the current model if there is insufficient liquidity on the destination for a given bridge to complete a transaction within some defined slippage constraints. This case is not well-handled by bridges at the moment. Bridges are forced to either output some wrapped representation, or force users to wait until there is more liquidity. 
+    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
+
+This proposal 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.
+
+With `XERC20`, the above problems are solved elegantly:
+
+1. Because `XERC20`s are able to be transferred 1:1 across chains (i.e. they have uniform pricing), aggregators are largely incentivized to route `XERC20` transfers based on *available limits* for a given asset (as transferring over a bridge with insufficient limits would result in a negative experience for their users). In other words, aggregators now route based on a **token-issuer-defined** metric of the perceived security of a given bridge. This radically improves the incentives around secure bridge development, pushing bridges to optimize for security in order to receive the highest possible rate limits for a given token. Perhaps most importantly, this definition of security is sovereign to the token issuer, eliminating the need for aggregators, chains, or other ecosystem actors be "central planners" on determining a given bridge's security model.
+2. With slippage-free `XERC20` transfers, aggregators can know precisely how many tokens will get bridged across chains, eliminating headaches and custom code around sourcing destination-chain liquidity from DEXes. This massively improves pricing for users and composability for developers who want to build across chains.
+
+
+## Backwards Compatibility
+
+This proposal is fully backwards compatible with ERC-20.
+
+### Compatibility with ERC-7802 Crosschain Token Interface
+
+ERC-7802 introduces `crosschainMint` and `crosschainBurn` functions for bridges, while `XERC20` uses "regular" `mint` and `burn` functions. The interfaces are compatible and can coexist within the same contract with the shared business logic.
+
+Example:
+
+```solidity
+    /**
+     * @notice Mint tokens through a crosschain transfer by the bridge using ERC7802 and ERC7281 limits.
+     * @param to     Address to mint tokens to.
+     * @param amount Amount of tokens to mint.
+     * @dev A facade to the `mint()` function with additional event
+     * @dev whenNotPaused modifier is applied within mint transfer call
+     */
+    function crosschainMint(address to, uint256 amount) external virtual {
+        mint(to, amount);
+        emit CrosschainMint(to, amount, msg.sender);
+    }
+```
+
+
+### Compatibility with Bridges
+
+One key benefit to the `XERC20` model is that the simple requirement of a burn & mint interface makes this proposal compatible with most bridges either out of the box or through a predefined custom token mapping process. The following bridges & domains were considered in the creation of this proposal:
+
+- **3rd party bridges:** every 3rd party bridge that relies on messaging infrastructure already supports a mint and burn interface and has a pathway to map custom minted tokens.
+- **Arbitrum rollup bridge:**  Arbitrum allows token issuers to write a custom gateway
+- **OP Stack bridge:** Optimism supports adding a custom bridge
+- **Polygon PoS bridge:** Polygon supports custom tokens through their fx portal
+- **ZkSync bridge**: Zksync supports custom bridges of any kind
+- **GnosisChain Omnibridge:** GnosisChain does not currently support custom tokens, but is in the process of redesigning their omnibridge and plans to allow this functionality.
+
+Note: In most of the above cases, a custom bridge integration also means integration into canonical bridge UIs, ensuring that users have a consistent experience throughout the process. Additionally, a single `XERC20` custom bridge implementation could be built for each ecosystem and serve any number of token issuers.
+
+## Security Considerations
+
+In addition to the granular risk controls outlined in the [Rate Limits](#rate-limits) section, token issuers should be aware of the following security considerations.
+
+### Mint/Burn Checks
+
+To reiterate security points from the [Token Interface](#token-interface-for-bridged-tokens) section:
+
+- `mint` MUST check that the caller's current available minting `limit` is greater than or equal to `_amount`
+- `mint` MUST increase the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
+- `burn` MUST check that the caller's current available burning `limit` is greater than or equal to `_amount`
+- `burn` MUST decrease the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).