If you haven’t read Part I of the How To Make Cross-Chain Tokens Fungible Again series, you may want to check it out first—it breaks down why bridged tokens lose fungibility and the challenges this creates. In Part II, we explore ERC-7281, a new standard that streamlines cross-chain token transfers, enhances reliability, and gives issuers greater control.
The Need For A Better Approach
So far, we’ve explored various solutions to the problem of making bridged tokens fungible and solving issues around liquidity fragmentation and poor UX from non-canonical representations of a native token circulating on non-native blockchains:
- Mint canonical representations of a token on remote chains via canonical rollup/sidechain bridges
- Mint canonical representations of a token on remote chains via a third-party bridge service
- Mint canonical representations of a token on remote chains via a canonical bridge service operated by the token issuer
Each of these approaches displays tradeoffs, so it’s only fitting that ERC-7281’s proposal for creating fungible bridged tokens attempts to take the best from each approach to create a more holistic, efficient, and accessible solution for protocols that wish to deploy tokens cross-chain without trading off security, sovereignty, or user experience.
ERC-7281: Sovereign-Bridged Tokens is a proposal to enable the creation of canonical representations of a token that are compatible and fungible with representations minted by many different bridges. ERC-7281 works by extending the ERC-20 interface to include:
- Functionality for minting and burning canonical ERC-20 tokens;
- Token owner’s ability to
1) assign bridge operators to minting and burning tokens when bridged between chains;
2) Rate-limit minting and burning of tokens for each approved bridge operator—for example, setting small limits for centralized bridges and higher ones for more secure protocols.
Given the slight difference between ERC-7281 and ERC-20 tokens, the EIP authors have described the former as “xERC-20”. For readers who require an overview of ERC-20 tokens, OpenZeppelin has a great guide on the topic.
In essence, each ERC-20 token contract implements the ERC-20 interface that defines a global token supply and stores information about which addresses own the token and how much they own. ERC-20 also includes useful functions for managing access to a user’s tokens (via approvals) and retrieving information about a token—like the total circulating supply and balance of a particular address.
One extra feature ERC-7281 adds to the ERC-20 specification is an optional Lockbox that functions as a wrapper contract (similar to the WETH (Wrapped Ether) contract). The Lockbox contract wraps ERC-20 tokens into xERC-20 tokens through familiar mint-and-burn mechanisms and makes ERC-7281 compatible with existing ERC-20 token contracts that lack a burn/mint interface and are non-upgradeable.
Using the framework introduced in the previous article, we can categorize ERC-7281 as a “trust the token issuer + trust the (approved) bridge provider” approach to minting multichain tokens. An ERC-7281 token deployed across multiple chains is controlled by its issuer (unlike alternative designs of cross-chain tokens that usually require giving up sovereignty). Although the issuer is still exposed to the risk of an approved bridge suffering a security incident, the issuer manages this risk by manually choosing and rate-limiting authorized bridge providers.
The big difference, which we’ll explore in this report, is that token issuers can calibrate exposure to bridge hacks and exploits by imposing dynamic limits on how many tokens a particular bridge operator can mint/burn. ERC-7281 also allows a token issuer to whitelist multiple bridge providers to mint the same canonical token across chains, reducing reliance on a single provider to process cross-chain bridging operations.
Both features make ERC-7281 a significant improvement over traditional approaches to facilitating cross-chain bridging of a protocol’s tokens and have positive second-order effects for users, interoperability infrastructure providers (especially aggregators), and application developers. After discussing the specifications in the next section, we’ll review the advantages—and disadvantages—of implementing ERC-7281.
An overview Of ERC-7281: Sovereign bridged tokens
Burning and minting tokens for users
In the specification, a project deploys a new ERC20-compatible token contract that implements the IXERC20 interface. Bridge operators mint tokens for users on the destination chain after burning a deposit on the source chain. The minting process checks that the token amount does not exceed the bridge’s limit and updates the token’s total supply and the bridge’s minting limit if successful.
For already existing ERC-20 tokens, a “lockbox” logic is applied: the bridge provider wraps ERC-20 tokens deposited by users into xERC-20 tokens by transferring them to a Lockbox contract. The Lockbox then approves the bridge to mint an equivalent amount of xERC-20 tokens.
xERC-20 tokens minted by a bridge on the destination chain are burned on the source chain using the burn() function. This process ensures that the token amount does not exceed the bridge’s burning limit, increases it, and decreases the xERC-20 token’s total supply. The bridge’s transport layer relays the burn message to the destination. The bridge contract on the destination side verifies the message and mints an equal amount of xERC-20 tokens to the user’s address on that chain. This minting decreases the token’s total supply and the bridge’s minting limit.
To bridge tokens back to the home chain, the bridge operator burns xERC-20 tokens on the remote chain, providing the user’s address and token amount. The burn receipt is relayed to the home chain by the transport layer. If the burn message is verified, the bridge operator mints and burns new xERC-20 tokens on the home chain for the user. Upon validation of the burn receipt by the token contract, the bridge operator releases the deposited ERC-20 tokens to the user. Burning xERC-20 tokens on the home chain reduces the token’s total supply and the bridge’s burning limit.
An important point: the xERC-20 contract can technically mint tokens without the bridge verifying proofs. We’ve described the standard (read: expected) approach, but bridges that do not implement any type of message verification—or implement novel mechanisms for verifying cross-chain messages—can be whitelisted to mint and burn xERC-20 tokens. It all depends on what the token issuer can accept.
Rate limits for token minting and burning
The function setBridgeLimits is a protected function that can only be called by the token contract owner. This function allows setting the address of the bridge contract and specifying the maximum amount of tokens the bridge can mint (mintingLimit) and burn (burningLimit) for users. The owner can update these limits, enabling adjusting the bridge’s capabilities as needed. For example, if security issues are discovered in a bridge provider’s infrastructure, the mintingLimit can be reduced to minimize risk. Conversely, security improvements may lead to an increase in the minting limit.
The xERC-20 specification also includes functions to check the burning and minting limits for bridges approved to handle the token. “mintingMaxLimitOf” returns the maximum amount of tokens a bridge can mint, and respectively, “burningMaxLimit” returns the maximum amount of tokens a bridge can burn during a specified period. Additionally, these functions show the remaining tokens a bridge can burn and mint before reaching the preset limits.
These viewer functions are helpful for bridge aggregators who need to know the available limits for different bridge providers before routing transactions. If a bridge reaches its burn or mint limit on the source or destination chain, it can affect ongoing transactions and user experience. Therefore, aggregators prefer to route requests to bridges that haven’t reached their minting and burning limits and can perform the swap of a given amount.
Rate limit parameters
The xERC-20 token interface specification includes a “Bridge” struct containing “burningParams” and “mintingParams” (the parameters of an xERC-20 token’s rate limit function control how many tokens a bridge can burn and mint over a predefined period). “maxLimit” defines the maximum limit on token minting and burning and increases every second at a predefined rate (“ratePerSecond).”
This is where we address a possible point of confusion: “maxLimit” (set for both burning and minting limit) sounds like a cap on minting and burning operations on a particular timescale—not a rate limit that throttles minting and burning according to predefined thresholds during the preset time window. “currentLimit” defines how much a bridge can mint or burn and increases at a predefined rate. In contrast, “maxLimit” defines how much a bridge can mint or burn daily.
Burning and minting parameters are mainly relevant to token owners (and bridge operators to a lesser extent). However, the maximum and current limit parameters are important considerations for users and bridge operators. For example, the current limit could affect how much a user can confidently bridge with a cross-chain protocol without running into delays on receiving xERC-20 tokens at the destination.
xERC-20 Lockbox
The original ERC-20 token doesn’t specify functions for increasing and decreasing a token’s supply (back when “tokenomics” meant generating a fixed number of tokens and telling users the token had value because it would be scarce in a few years*). So, not every ERC-20 token has a minting and burning function. Since ERC-7281 uses the mint-and-burn mechanism favored by most (if not all) bridges today, legacy or non-upgradeable ERC-20 tokens cannot work out of the box with ERC-7281.
The Lockbox contract provides a workaround and enables backward compatibility with existing tokens. In the original specification (i.e., a project deploys a new token contract that implements the IXERC20 interface), bridge operators only have to call mint() to mint tokens for a user at the destination chain (after locking a deposit on the source chain).
The Lockbox contract borrows heavily from the design of the WETH wrapper contract. It implements a deposit() function to deposit the corresponding ERC-20 token in the Lockbox and a withdraw() function for bridge operators to unlock ERC-20 tokens after burning wrapped tokens on a remote domain.
The first two error types highlighted in the specification (“IXERC-20Lockbox_NotNative” and “IXERC-20Lockbox_Native”) occur when a user attempts to deposit tokens in the wrong Lockbox contract. A Lockbox can be native or non-native, depending on what types of tokens it supports.
Native Lockboxes custody native tokens—that is, tokens used to pay gas fees to validators. An example of a token that would have a native Lockbox for wrapping it into an xERC-20 token is ETH: wrapping ETH into an xERC-20 token would require calling the Lockbox's depositNative() function and depositing ETH to receive the ERC7281-compatible representation of ETH.
Regular (non-native) Lockboxes custody ERC-20 tokens like USDC, DAI, WETH, USDT, etc. To mint USDC as an xERC-20 token, for example, the user would call deposit() on the Lockbox contract after locking USDC.
Calling deposit() with ETH would result in those funds being locked forever since the regular Lockbox contract can only wrap and unwrap ERC-20 tokens. Calling depositNative() with an ERC-20 token would produce similar results as native Lockbox contracts are meant to work with native tokens, not ERC-20 tokens.
This way, by wrapping canonical ERC-20 tokens into xERC-20 tokens with mint/burn support, the Lockbox provides an important compatibility layer for the standard. However, for some cases, such as integrating other bridging solutions into xERC-20, using just the lockbox, and returning the wrapped token is not an option. For this reason, projects may implement adapter contracts.
Adapter contracts
In cases where bridging protocols are not designed to recognize the operations inherent to xERC‑20 tokens (mint/burn, corresponding logging, and such), apps can build adapter contracts. These contracts function as automated wrappers and unwrappers—effectively translating standard ERC‑20 approve + call behavior into a more nuanced mint/burn scheme required by xERC‑20.
This is necessary because many bridge protocols (for example, Chainlink’s CCIP) remain optimized for the conventional ERC‑20 behavior. The adapter contract can bridge (ba-dum-tss) this compatibility gap by enshrining such logic: it deposits tokens into the Lockbox to generate the xERC‑20 representation on the source chain, and later, upon message receipt on the destination chain, it triggers the withdrawal mechanism to revert to the canonical asset.
This flow ensures that the user ultimately receives a consistent, canonical token—unaffected by wrapping mechanisms powered by xERC-20 under the hood. This way, adapters can let protocols seamlessly integrate with non-xERC‑20‑compliant bridges and increase the spectrum of interoperable solutions that they support.
Why ERC-7281? The case for a sovereign bridged token standard
At a high level, ERC-7281 has four broad goals:
1. Fungibility: Users bridging tokens from the token’s native chain to another (L1/L2) chain should always receive canonical representations of the bridged token at the destination. Multiple non-fungible versions of the same token circulating in a non-native chain are problematic for reasons explained previously (e.g., liquidity fragmentation and poor token composability).
The original vision for creating the ERC-20 specification was to ensure fungibility and seamless interoperation between tokens on Ethereum across applications and Ethereum infrastructure. However, after adopting a rollup-centric scaling roadmap, the problem of lack of atomic composability arose, and the creation of many different domains degraded those fungibility properties. xERC-20 allows aggregating the liquidity of various cross-rollup bridges into unified multi-rollup tokens, restoring Ethereum’s initial vision.
2. Security: To reduce counterparty risk, token issuers should have the option to select from competing bridge providers according to the assessment of security infrastructure. Furthermore, token issuers should have meaningful protection from the fallout of security incidents affecting partner bridge providers—isolated attacks on one or two bridge services shouldn’t wipe out entire TVLs.
3. Liquidity-free bootstrapping for cross-chain tokens: Protocol DAOs shouldn’t be forced to expend significant (financial) resources on bootstrapping liquidity for bridged tokens as part of multi-chain expansion plans. Not only is liquidity-based bridging poor for UX, but spending on liquidity provision incentives may become infeasible for project teams as the number of blockchains increases shortly.
4. Sovereignty for token issuers: The token issuer should remain in control of the canonical representation of protocol tokens minted on non-native chains. Solving the problem of non-fungible bridged tokens shouldn’t require handing off control of a project’s bridged token—especially administrative aspects like controlling total supply and configuring minting and burning mechanisms—to a third-party bridge.
We can further expand on these goals to see what benefits ERC-7281 provides for protocols and communities.
Analyzing the benefits Of ERC-7281
Improving UX and eliminating liquidity fragmentation
ERC-7281 solves various versions of the path dependence problem described in the introduction.
Path dependence can be chain-specific (e.g., ETH bridged from Ethereum → Arbitrum → Optimism is different from ETH bridged from Ethereum → Optimism → Arbitrum) or bridge-specific (e.g., ETH bridged from Ethereum to Optimism via Celer is different from ETH bridged from Ethereum to Optimism via Connext).
Path dependence is a valuable security feature, but it can also be detrimental to bridging UX and cross-chain composability. For example, a user cannot programmatically supply liquidity to a cross-chain DEX operating on Optimism and Arbitrum as the application must accept opETH or arbETH.
ERC-7281 eliminates the problem by introducing xERC-20 tokens that remain fungible no matter how many times a user bridges across chains or what bridge providers are used to bridging tokens. Suppose a user wishes to move wrapped USDT from Arbitrum to Optimism without withdrawing to Ethereum first; a bridge provider can burn xERC-20 tokens on Arbitrum and mint xERC-20s on Optimism — the value of tokens minted on Optimism is still pegged to tokens deposited in the Lockbox and are remapped to maintain their 1:1 backing.
Importantly, ERC-7281 provides the benefits of deploying a canonical bridged token like Circle’s CCTP (Cross-Chain Transfer Protocol) without requiring the protocol to have centralized custody of bridged tokens. For example, liquidity is consolidated around the canonical representation of a project’s token, which improves token utility for DeFi applications and reduces the overhead of creating different markets for different versions of the same asset.
Bolstering sovereignty for token issuers
xERC-20s are described as “sovereign-bridged tokens” as token issuers aren’t locked into using a particular option for minting canonical representations of a token and retain control of the design and administration of bridged tokens across deployments. ERC-7281 is a hybrid between “minting canonical tokens via a third-party bridge” and “minting canonical tokens via a token issuer-controlled bridge” that combines sovereignty, user experience, and decentralization in the same package.
Projects that deploy tokens cross-chain with ERC-7281 can mint canonical representations of native tokens via multiple bridges without running into the issue of non-fungible wrapped versions of the same native asset, breaking UX for users hoping to leverage composability and fungibility of ERC-20 tokens. Such projects also retain a similar level of control over cross-chain deployments of a token as a token issuer running in-house infrastructure to manage transfers of canonical tokens between domains since xERC-20 token contracts and Lockbox—which bridges utilize to lock, mint, and burn tokens for users—are deployed and controlled by the project.
This understated feature can be handy in cases where a high-profile project has a native token issued on the home chain. Users from other ecosystems want exposure to the token without holding it on its native chain for different reasons.
Still, the project doesn’t have the capacity or willingness to run in-house bridging infrastructure for every chain to ensure 1:1 compatibility between bridged tokens—nor does it want to fork over control of its token to a third party not necessarily aligned with the protocol and its community. Such a case becomes a consideration when implementing cross-chain governance that allows voting with bridged tokens while votes are tallied on the native chain; a non-aligned bridge provider with control of bridged tokens becomes a choke point for protocol governance.
Beefy, a yield farming protocol, has also adopted xERC-20 for this reason. As the project’s bridge documentation describes it, ERC-7281 provided the project with more options for bridging tokens—which had become necessary after a major bridge partner suffered a hack (a theme that’s rapidly becoming familiar to crypto-natives)—and provided more fine-grained control of the design of bridging mechanisms. In Beefy’s case, ERC-7281’s allowlisting feature enabled the protocol to select various bridging partners and offer users different options between optimizing for speed, decentralization, costs, and security when bridging mooBIFI tokens.
Realignment in incentives improves open competition and security
Liquidity-based bridging often favors projects with the financial capacity to spend on liquidity incentives — since token issuers want to spend little on LP incentives and offer superior bridging UX, liquidity becomes the most crucial factor for protocols using canonical L1/L2 bridges. This also extends to the selection of bridge providers by bridge aggregators, arguably making it harder for new bridging services (even those with secure infrastructure) to compete with more established bridging protocols.
ERC-7281 remedies the problem by removing the need for liquidity-based bridging. Without the need to mint and swap non-canonical tokens for canonical tokens, bridges of any size can be approved to mint a project’s token on a remote domain. Since token issuers want to minimize exposure to bridge failures, more protocols will likely start paying more attention to the security designs of cross-chain bridges instead of focusing on liquidity first.
This incentivizes open competition as it becomes a case of “let the most secure bridge win” and not “let the most liquid bridge win”; this open competition can take the form of bridges competing on more features beyond liquidity/security (e.g., fees, APIs/SDKs, application integrations, etc.). These features are arguably easier to bake into an application from the start as they primarily depend on the development team’s expertise; in contrast, liquidity and bridging volumes are more complex to bootstrap and require a mix of business development, funding, industry connections, marketing, and more.
Better risk management for token issuers
ERC-7281 introduces a configurable rate limit on token minting and burning that dramatically improves the risk profile for protocols working with third-party bridges to mint canonical tokens on non-native chains. Should a partner bridge provider be hacked or compromised, the most damage an attacker can cause is equivalent to the limit assigned to the compromised bridge. If a token issuer chooses rate-limiting parameters carefully, isolated attacks on a bridge should have minimal impact on the protocol’s solvency.
Configuring rate limits per bridge may also improve the risk assessment process for protocol DAOs. Currently, bridge risk assessment can take months to complete due to the magnitude of impact from a canonical third-party bridge getting hacked; protocols want to make sure to make defensible decisions, where the security of the chosen bridge is scrutinized extensively to give the community stronger guarantees of safety. Besides being unnecessarily wasteful of effort and time, marathon analyses of bridge security still don’t guarantee that a chosen bridge is immune to zero-day exploits.
Adopting ERC-7281 makes risk assessment more dynamic. Projects still have to complete due diligence on bridge providers to choose appropriate rate-limiting properties; however, risk evaluation timelines can be reduced to reflect that protocols are no longer in an all-or-nothing position. Instead of spending months analyzing several bridges to pick one option, a project can spend half the time picking multiple bridge providers initially and setting varying minting limits based on an assessment of security. The token issuer can then conduct security reviews to determine whether to increase or decrease minting limits for select bridging partners or withdraw minting rights from a bridge (e.g., in response to a hack or vulnerability disclosure).
ERC-7281 also reduces the barrier for projects that wish to opt into cutting-edge advancements in bridge security but are hesitant to adopt a particular technology in its entirety until the tech has been battle-tested and vetted rigorously by the community (i.e., the innovator’s dilemma). Suppose a bridge provider proposes a new infrastructure that reportedly substantially improves security guarantees. In that case, a protocol can “test the waters” by assigning limited minting rights to the bridge and progressively increasing the bridge’s minting limit as confidence in the proposed system design rises.
Just like removing liquidity-related concerns, removing the need for a protocol to trust a bridge’s tech stack 100% before assigning minting rights creates equal competition between new entrants and old players—old players have the incentive to iterate on better approaches to security since token issuers now have the flexibility to withdraw minting rights and reassign to a smaller project just because the latter has demonstrated a higher commitment to safety and decentralization. This also eliminates another risk factor for protocols working with third-party bridges: the risk that a selected bridge provider stops innovating on security despite the rapid pace at which flaws and issues in bridge security are disclosed and discovered because it knows the token issuer cannot enforce punitive actions (e.g., migrating to another bridge provider) due to the difficulty of executing such activities.
Improving composability between ecosystems
Building complicated application workflows that require routing tokens through any number of chains is difficult today due to the unpredictable pricing of liquidity-based bridges. For example, a bridge aggregator bridging from Ethereum → Linea → Base has two options:
- Set a slippage tolerance parameter and price execution of cross-chain routing based on the minimum amount of tokens a user will receive on each chain (depending on the amount of liquidity available when the bridging message arrives at each layer).
- Don’t set a slippage tolerance parameter; instead, create logic to source on-chain liquidity (e.g., via DEXes) if the amount of tokens received on one or more chains is lower than the expected amount.
In comparison, bridge aggregators can know upfront how many tokens they should expect on each domain involved in a cross-chain transaction by checking mintingLimit and burningLimit for bridges allowed to mint a particular token. Admittedly, a bridge can hit maxLimit between the time of broadcasting the transaction and the transaction reaching a domain—which means the user cannot receive canonical tokens at the destination.
However, ERC-7281 is still an improvement in this regard for the following reasons:
- If a bridge operator hits mintingLimit while a transaction is in-flight, the bridging transaction is held and retried later when the rate limit parameters adjust. Users don’t receive a proprietary wrapped representation of the canonical token—unlike with liquidity bridges today.
- Bridge aggregators have more predictability around when a bridging transaction will execute and the number of tokens to expect. Since mintingLimit and burningLimit are configured to use blocks as a measure of time (as shown in the section on rate limiting parameters), it’s easy to calculate when a bridge will start minting and burning tokens again; in contrast, predicting when liquidity will increase in a bridge is the equivalent of playing Russian roulette.
Unpredictable shifts in liquidity also mean unpredictability in the pricing of retried bridging transactions. Suppose a bridge aggregator (or another application) places a quote for a cross-chain swap based on the current price of a token pair in a bridge’s liquidity pool (this price is based on total pool liquidity). Still, the transaction cannot execute due to a sharp decrease in pool liquidity. Suppose the trade is held and retried later. In that case, the application developer cannot know if the previous quote remains accurate or if liquidity will reach the same levels as when the user first submitted the transaction.
Since bridging xERC-20 tokens isn’t subject to liquidity movements, users can be confident that cross-chain transactions won’t incur slippage—even if they don’t execute immediately.
Bridging aggregators aren’t the only ones to benefit from this improvement in composability; any cross-chain application can harness the fungibility of xERC-20 tokens to create more exciting applications. This is more difficult today due to problems around path dependence: suppose a developer wishes to bridge ETH from Ethereum, open a lending position on an Arbitrum DEX, and use the profits to buy an NFT on Optimism before bridging back to Ethereum. Here, the developer must ensure to integrate with bridge providers on those chains—since you can’t easily swap proprietary versions around—which isn’t the case once a project’s bridged tokens are fungible after adopting xERC-20.
This workflow is similar to the token-issuer bridges described earlier. Let’s take Circle CCTP as an example:
Circle’s Cross-Chain Transfer Protocol allows users to have a unified, canonical version of its USDC token without being trapped in the ecosystem of their chains. All cross-chain transfers are processed through its protocol using the burn-and-mint scheme.
However, while CCTP is a centralized protocol, as Circle’s operators are the only entities that are authorized to burn and mint its USDC tokens, xERC-20 liquidates the trust risk by allowing multiple entities with various security mechanisms to operate cross-chain transfers.
Supporting Ethereum’s vision of a rollup-centric, multichain future
ERC-7281 can accelerate Ethereum’s rollup-centric roadmap by giving projects the confidence to deploy tokens on new EVM L2s that may lack the strong security profiles of established L2 chains. For example, the canonical bridge of a stage 0 rollup is less secure since Ethereum L1 does not guarantee the bridge's security. A token project can slowly roll out to such a chain by granting limited minting rights to the canonical bridge and increasing the minting limit once the rollup advances to stage 1.
This process can continue until the L2 reaches stage 2 (the highest stage of decentralization and security for a rollup). A mechanism whereby protocols can deploy on newly launched chains in a risk-minimized fashion benefits the Ethereum ecosystem by making it easier for new L2s to bootstrap token liquidity and applications while encouraging more innovation within the rollup design space.
Potential drawbacks of implementing ERC-7281
Increased overhead for DAO project management teams
While ERC-7281 is very attractive for protocols, DAOs may hesitate to adopt xERC-20 tokens due to the significant operational overhead that DAO project teams must incur to manage xERC-20 tokens on various deployments.
Gerard Persoon’s Manage bridged tokens on a large number of chains includes a non-exhaustive list of one-time and recurring tasks that the protocol must carry out after migrating from ERC-20 to xERC-20:
That’s one very long list of tasks
A proposed solution is for DAOs to outsource some of these administrative tasks related to managing cross-chain xERC-20 tokens to third-party services, but this is merely exchanging one tradeoff (costs of human resources) with another (costs of hiring services).
Suppose a protocol previously managed cross-chain tokens with in-house infrastructure (e.g., deploying a separate token contract per chain and controlling minting and burning). In that case, ERC-7281 doesn’t seem like a radical change. However, projects used to outsource the management of core bridging infrastructure to bridge development teams will find the additional workload concerning.
For example, a core Lido team member outlined (in response to a proposal for Lido to deploy wstETH as an xERC-20 token across all deployments) the current responsibilities of the PM team concerned with interoperability infrastructure and contrasted the set with the set of responsibilities the same team members would have to assume if the Lido DAO voted to have wstETH on all domains migrated to an xERC-20 version.
As the above conversation shows, managing xERC-20 tokens imposes a non-negligible increase in administrative overhead for protocols and community members. For example, bridge limits require active monitoring and evaluation of bridge security to inform adjustments to minting limits, and decisions around bridge limits (or withdrawal/assignment of minting rights) may be subject to a DAO vote (if such choices need to be made frequently, DAO members may suffer voter fatigue).
This should not be construed as a value judgment on ERC-7281, however. Each project will have different risk profiles, long-term goals, and resources—and these factors collectively determine if the long-term benefit of adopting ERC-7281 outweighs the short-term and ongoing costs of doing so.
For example, smaller projects might find it harder to manage the overhead of issuing xERC-20 tokens and choose to opt for a managed multichain token bridging service like Axelar’s ITS (Interchain Token Service) or Wormhole’s NTT (Native Token Transfers). More established projects may have the resources to manage the administrative and operational costs of issuing an xERC-20 token and may consider the control afforded by ERC-7281 worth the extra overhead of managing cross-chain tokens.
Difficulties around migrating existing tokens to xERC-20 standard
For projects that don’t have a mint/burn interface, or cannot upgrade token contracts to use IERC20 via inheritance, and already have canonical representations of native tokens circulating on non-native chains, migrating to xERC-20 tokens is a lengthy process that requires a great deal of coordination and involves a complex web of participants—ranging from token holders, exchanges (DEXes and CEXes), partner bridges, and applications integrated with the legacy ERC-20 token. Even with this part handled, protocols still bear the cost of unwrapping ERC-20s into xERC-20s to complete the migration process.
As explained in the discussion of the ERC-7281 specification, existing tokens will need to be locked in the Lockbox to mint wrapped xERC-20s for users. Sunsetting the legacy ERC-20 happens shortly afterward and involves another prolonged process of sharing communication with the community around the timeline for freezing the minting of new (legacy) ERC-20 tokens. Again, this may be well worth the cost from a protocol’s perspective—although the benefits may also be insufficient to justify the costs of coordinating an ecosystem-wide migration to the xERC20-compatible representation of a protocol’s token.
Larger risk surface for DAO governance
Managing xERC-20 tokens on multiple domains with ERC-7281 requires active governance from the DAO overseeing the protocol. This involves setting parameters like minting limits, upgrading the Lockbox contract, and pausing minting or burning tokens. These decisions are security-sensitive and should be governed by the DAO to avoid the liability of closed boardroom decisions.
ERC-7281 aims to give protocols control over these decisions rather than third-party bridges. This makes sense, as DAOs already manage tokens on their native chains, so extending their governance to tokens on other chains is reasonable for protocols and communities seeking this control. However, some protocols may not want this extra DAO control due to concerns about governance and stability.
For example, high-profile projects like Lido face scrutiny over governance issues. Adding control over token management increases the risk of a governance takeover. A governance attack could have widespread effects if a project consolidates all ERC-20 tokens into a Lockbox and the DAO governs it. An attacker could gain control of the Lockbox and introduce a malicious bridge provider with no minting limits, making xERC-20 tokens on other chains worthless.
This scenario has parallels with the Multichain exploit, where a vulnerability in the multiparty computation (MPC) signing infrastructure allowed hackers to compromise the primary Multichain addresses that were custodying native tokens on Ethereum and Dogecoin—these tokens backed tokens minted on non-native chains like Fantom and Moonriver, which created a domino effect that resulted in projects elsewhere suffering losses as a result of the attack on Multichain’s smart contracts on Ethereum and Dogecoin.
Incompatibility with maximally decentralized protocols
ERC-7281 fits the purpose when the token is issued by a protocol with token governance or a centralized entity (e.g., Circle’s USDC or the CZKC stablecoin). However, it’s not as valuable if the protocol is maximally decentralized and lacks formal governance—Liquity’s LUSD stablecoin is an example of a token that would be difficult to make compatible with the xERC-20 standard.
The xERC-20 token requires an entity to decide on specific parameters like minting and burning limits and make decisions like whether to whitelist certain bridge providers or not. This implies the need for continued governance for the existence of the xERC-20 token. For projects that wish to decentralize critical components of the protocol—such as the DAO’s token contract—over time, this may cause issues and complicate decentralization plans.
Larger risk from exploits affecting core components (Lockbox contract and bridge providers)
We already mentioned how path dependence works and why it helps provide guarantees that an exploit affecting chain A will not affect chain B, or that an exploit involving bridge A on chain A will not affect bridge B on chain B. ERC-7281 removes path dependence, which has benefits, but also introduces a tradeoff around security:
The maximum available liquidity in a bridge no longer represents an upper bound on the potential impact of a bridge exploit on the token issuer, as tokens minted by different bridge providers are fungible across domains. ERC-7281’s authors propose to choose a rate limit for bridge providers based on the amount a token issuer can spend to compensate for losses from fraudulent minting; even so, a selected rate limit may have been too conservative in retrospect.
If a bridge with a high limit is compromised, the effects can be pronounced—even for users of other bridges minting the same token. Protocols can reduce the risk by distributing minting rights across a broad number of bridges (so one bridge provider doesn’t have an outsized number of tokens it can mint compared to other bridges), but trying to hedge risk this way may increase inefficiency as each bridge will require independent assessment from the DAO team and coordinating with more bridges increases the administrative overhead we mentioned earlier.
The Lockbox contract governed by a DAO could introduce adverse contagion effects in the event of a governance attack. But even with secure DAO governance, a bug in the native/non-native Lockbox contracts on the token’s home chain can cause just as many problems (Sifu is now the owner of the Lockbox contract for a project, and funds are no longer SAFU). In comparison, this problem is reduced in the status quo as vault contracts (the bridge provider’s equivalent of the Lockbox contract) only hold tokens bridged through the corresponding bridge service. So, a bug in the vault contract for one provider only affects the users who deposited tokens with that bridge.
Overhead for ecosystem integrations
The extra administrative work with ERC-7281 also affects application developers and service providers using a project’s xERC-20 token. Bridge aggregators need to keep track of mappings between xERC-20 tokens and their corresponding Lockbox contracts to prevent issues like spam tokens and spoofing attacks. While a registry of these mappings could help, setting up such a registry is challenging without risking centralization or exposing xERC-20 adopters to threats.
The risk comes from attackers potentially adding malicious contracts to the token registry and tricking users and developers into sending tokens to the wrong address. This could lead to token theft on both L2 and L1 networks. Exchanges face similar challenges, as spoofed tokens could cause serious problems, such as unexpected token behavior, which differs from the vetted canonical tokens.
Conclusion
ERC-7281 presents a compelling solution to the issues of non-fungible bridged tokens and offers features that enhance user experience, decentralization, security, and flexibility in token bridging designs. Some of these problems directly impact the viability of the rollup-centric roadmap, making the xERC-20 standard critical infrastructure for the Ethereum L2 ecosystem.
Several key players in the bridging space, including Hyperlane, Omni, Sygma, Router Protocol, and Everclear, have committed to adopting ERC-7281, indicating significant traction for the proposal. Even established token issuers (who have working mechanisms for bridging tokens)—such as Circle—have shown interest in ERC-7281 to address the challenges posed by unapproved tokens affecting users and developers.
ERC-7281 addresses these issues while mitigating many trade-offs associated with previous approaches to minting canonical tokens on remote domains. It provides liquidity-free bootstrapping, unlike enshrined bridges, does not require custom infrastructure like token-issuer bridges, and avoids vendor lock-in by allowing multi-bridge canonical token minting by approved bridge providers.
For those interested in following the discussion around ERC-7281 or developers looking to integrate xERC-20, the Fellowship of Ethereum Magicians and the xERC-20 website are excellent resources. The community has also built an xERC-20 launchpad to aggregate tooling for creating, monitoring, and managing xERC-20 tokens—a valuable tool for builders looking to deploy an xERC-20 token for the first time or migrate an existing token to the xERC-20 token standard.