By Eco research. Updated Apr 2026.
​

ERC-7281, also known as xERC-20 or Sovereign Bridged Tokens, is an Ethereum token standard that gives token issuers direct control over which bridges can mint and burn their token across chains, with configurable rate limits per bridge. Proposed by Arjun Bhuptani of Connext in 2023, the standard solves a structural security problem in multi-bridge ecosystems: when multiple bridges each hold or mint the same token, a single bridge exploit can drain the entire cross-chain supply unless explicit caps exist per bridge.
​

ERC-7281 is an Ethereum Improvement Proposal that extends ERC-20 with a bridge registry and per-bridge rate limits on token minting and burning. Token issuers deploy a canonical contract tracking which bridges can call mint or burn, and how many tokens each bridge may issue in a rolling window. Authored by Arjun Bhuptani and the Connext team, it was submitted to the EIP repository in 2023.
​

Before ERC-7281, cross-chain token deployments typically followed one of two models: the issuer deployed a single bridge (centralized control but no exploit spread) or the market evolved multiple independent wrapped-token versions (USDC.e vs. bridged-USDC vs. native-USDC on Arbitrum is a concrete example of supply fragmentation). ERC-7281 introduces a third model: the issuer keeps canonical supply control and can authorize multiple bridges simultaneously, but each bridge operates within a rate-limited envelope that contains blast radius if exploited.
​

The standard addresses a gap that existed in the ERC-20 spec since Ethereum's earliest bridge designs: ERC-20 itself has no notion of authorized minters or rate limits. Any contract that the token issuer grants MINTER_ROLE can call mint() without restriction. In practice this meant that adding a second bridge to a token's cross-chain deployment required granting it full, uncapped minting rights: the same rights as the original bridge. ERC-7281 replaces that binary permission model with a graduated, time-windowed one that lets issuers authorize 10 bridges simultaneously while ensuring none of them can single-handedly drain the supply.
​

The ERC-7281 discussion thread on the Ethereum EIPs repository captures the original design rationale. Bhuptani's framing was explicit: "The goal is to give token issuers sovereignty over their token's cross-chain representation while still allowing competitive bridge markets to develop."
​

An ERC-7281 contract stores a bridge registry mapping each bridge address to two values: maxLimit (the token ceiling for that bridge) and currentLimit (remaining mintable balance in the current window). When a bridge calls mint, the contract checks against currentLimit and reverts if exceeded. The limit regenerates automatically over the configured window, requiring no governance transaction per cycle.
​

The mint and burn flow works as follows. A user initiates a cross-chain transfer on an authorized bridge. The origin chain's bridge contract locks or burns the user's tokens on the source side. The destination bridge contract calls mint on the ERC-7281 contract for the equivalent amount. The ERC-7281 contract validates that the calling bridge address is in the authorized registry and that the mint amount falls within the remaining currentLimit. If both checks pass, tokens are issued. If either fails, the transaction reverts.
​

The rate-limit window is the central security mechanism. If a bridge is compromised and an attacker attempts to mint the entire supply allowed to that bridge, they can extract at most maxLimit tokens before the currentLimit reaches zero and further mints revert. Without this cap, a single bridge exploit on a multi-bridge ecosystem could drain the entire cross-chain float. The reference implementation by DeFi Wonderland ships the full registry logic and a factory for deploying compliant tokens across chains, including a lockbox contract that wraps existing ERC-20 tokens for backward compatibility with legacy bridge flows.
​

The lockbox pattern is important for upgrades. Token issuers migrating an existing ERC-20 to xERC-20 cannot redeploy the original token contract on chains where it already has holders. The lockbox wraps the canonical token and exposes xERC-20 mint/burn interfaces to authorized bridges while preserving backward compatibility with wallets and protocols that hold the original ERC-20 address. This lets Circle, for example, run native USDC alongside older bridged-USDC deployments during a migration window.
​

ERC-7281 solves exploit contagion in multi-bridge token deployments. Without rate limits, every bridge holding mint authority over a token is an uncapped exposure: one compromised bridge can drain the full cross-chain supply. ERC-7281 replaces unbounded mint authority with issuer-governed, time-windowed caps per bridge, containing any exploit's damage to that bridge's allocated quota rather than the full float.
​

The scale of the problem this addresses is concrete. The Wormhole bridge exploit in February 2022 resulted in 120,000 Wrapped Ether (WETH) being minted fraudulently, worth approximately $320 million at the time. The Ronin bridge hack in March 2022 drained $625 million. Neither incident would have been fully preventable by ERC-7281 (both involved validator key compromise rather than uncapped mint authority alone), but ERC-7281 rate limits would have truncated the maximum extractable amount to the bridge's configured daily or weekly limit rather than the full custodied float. The Rekt.news bridge hack leaderboard documents over $2.5B in bridge-specific losses through 2024, the majority in uncapped mint-authority scenarios.
​

A secondary problem ERC-7281 solves is token supply fragmentation. Without a canonical standard, each bridge deploys its own wrapped-token contract (USDC.e on Arbitrum, multiUSDC on Fantom, etc.) creating liquidity fragmentation, DeFi integration complexity, and user confusion. With ERC-7281, the issuer deploys one canonical xERC-20 contract and all authorized bridges use the same token address. Protocols building on top of the token integrate once and gain multi-bridge redundancy automatically.
​

ERC-7281 and OFT (Omnichain Fungible Token, LayerZero's cross-chain token standard) both enable tokens to move across chains by burning on the source and minting on the destination, but they differ significantly in who controls the bridge registry and how security isolation is achieved. ERC-7281 is issuer-sovereign and bridge-agnostic; OFT is LayerZero-native and inherits LayerZero's oracle and relayer security model.
​

The table below compares the two standards across the dimensions most relevant for a token issuer choosing a cross-chain architecture.
​

The key differentiator is issuer sovereignty. An OFT deployment commits the token to LayerZero's security model: if LayerZero's oracle or DVN (Decentralized Verification Network) is compromised, the token's cross-chain minting is compromised. An ERC-7281 deployment lets the issuer authorize LayerZero as one of several bridges, each with its own rate limit, so LayerZero compromise caps out at that bridge's allocated quota rather than the full supply. The LayerZero OFT documentation acknowledges this trade-off: OFT is optimized for teams that want a single bridge provider with deep chain coverage rather than multi-bridge redundancy.
​

For issuers that need bridge-provider diversification (a stablecoin issuer that cannot accept full-supply exposure to any single bridge's security assumptions, for example), ERC-7281 is the better fit. For protocol tokens with no regulatory constraints on bridge selection and a need for fast, wide chain coverage, OFT's unified security model is simpler to operate.
​

Adoption of ERC-7281 in production has been concentrated among bridge protocols and token issuers with explicit multi-bridge requirements. Connext itself integrated xERC-20 support natively; Across Protocol, Li.Fi, and Hyperlane each released xERC-20 compatibility in 2023 and 2024. On the issuer side, the standard attracted attention from teams that experienced bridge-exploit contagion risk firsthand or that needed to retire fragmented wrapped-token deployments.
​

Frax Finance deployed xERC-20 for frxETH cross-chain transfers in 2024, authorizing multiple bridge providers with distinct rate limits. Frax's rationale was explicit in governance documentation: no single bridge should have uncapped access to frxETH mint authority. The governance post specified daily rate limits per bridge at 5,000 frxETH for smaller integrations and up to 50,000 frxETH for primary bridge partners, with the ability to adjust limits through a governance vote rather than a full contract upgrade. Alchemix similarly integrated xERC-20 for alETH cross-chain deployments, configuring per-bridge daily limits through the DeFi Wonderland factory contract.
​

Connext's own NEXT token was migrated to xERC-20 in 2023, serving as a live production demonstration of the standard the team designed. The migration allowed NEXT to route onchain across Connext's bridge network while preserving compatibility with existing DEX liquidity pools that held the pre-migration ERC-20 address, enabled by the lockbox pattern.
​

The ERC-7281 GitHub discussion as of Q1 2026 shows 47 distinct protocol teams commenting or signaling adoption intent, including stablecoin issuers, liquid staking protocols, and DeFi lending markets. The standard has not yet reached "final" EIP status, which has slowed enterprise adoption: issuers building regulated products (stablecoins, RWA tokens) prefer final EIP status for internal governance and audit purposes. The Ethereum Foundation's EIP process classifies ERC-7281 as "review" as of April 2026. The review classification means the specification is stable enough for production deployments but retains the ability to incorporate minor amendments before finalization.
​

Bridge protocol adoption is broader than issuer adoption at this stage. Most major bridge aggregators and cross-chain messaging protocols have added xERC-20 compatibility to their destination adapters. A bridge that wants to serve xERC-20 tokens adds a simple call path: instead of calling a bridge-specific locked-token contract, it calls mint on the ERC-7281 contract. If the bridge address is registered and within its rate limit, the call succeeds. This backward-compatible plug-in model means bridges can support xERC-20 tokens without redesigning their full bridging stack, which accelerated adoption on the bridge side relative to the issuer side.
​

ERC-7281 occupies a specific layer in the cross-chain security stack: it addresses mint-authority control at the token contract level, not at the messaging or consensus layer. It does not make bridges more secure internally; it limits the damage a compromised bridge can cause to a given token's supply. This is a meaningful distinction when evaluating what ERC-7281 can and cannot protect against.
​

Cross-chain token security operates at three distinct layers. The messaging layer (how the bridge transmits the transfer event from chain A to chain B) is where vulnerabilities like the Wormhole guardian key compromise occur. The bridge contract layer (how the bridge custodies or burns tokens) is where reentrancy, validation bypass, and approval-exploit vulnerabilities occur. The token layer (how mint authority is governed) is where ERC-7281 intervenes. Securing all three layers requires combining a robust bridge messaging protocol with audited bridge contracts and an ERC-7281 token contract that caps per-bridge exposure. No single layer substitutes for the others.
​

A practical example clarifies the interaction. Suppose a token issuer authorizes three bridges in its ERC-7281 registry, each with a 10,000 token daily cap. Bridge A is exploited through a message-layer validator compromise. The attacker, controlling Bridge A's contract address, calls mint on the ERC-7281 contract repeatedly. They can extract at most 10,000 tokens before currentLimit hits zero and further mints revert. Without ERC-7281, the same attacker could mint the entire cross-chain supply. With ERC-7281, the attack is bounded to 10,000 tokens regardless of how long the exploit runs. The rate limit regenerates the next day, but by that point the issuer can reduce Bridge A's maxLimit to zero through a governance transaction, effectively revoking its authorization.
​

The governance response speed matters. Most ERC-7281 deployments configure the issuer or a multisig treasury as the registry owner. A multisig with a 2-of-3 signing threshold can revoke a compromised bridge in hours, which is substantially faster than a traditional wrapped-token issuer who must coordinate a public announcement, contact the bridge team, and wait for bridge governance to act. Rate limits buy the issuer time to respond; governance control ends the exposure permanently.
​

For teams building on blockchain bridges, ERC-7281 provides the most value in multi-bridge deployments where no single provider is fully trusted. Teams using a single canonical bridge (for example, a chain's official canonical bridge for ETH deposits) gain less from the standard because there is only one mint authority to rate-limit. The standard's value scales with the number of bridge providers authorized: two bridges with a 50% daily mint quota each contain the maximum exploit to half the daily issuable supply rather than the full float.
​

Integration with cross-chain messaging protocols matters for ERC-7281 deployments. The rate-limit check happens at the token contract level, but the mint call is triggered by the bridge's message receiver on the destination chain. Message-layer exploits that forge a valid message with a legitimate bridge address bypass the rate limit if the bridge's own security model is broken. Rate limits contain supply damage but do not replace message-layer security. The combination of a secure messaging layer and ERC-7281 token governance is what teams like Connext and Hyperlane are building toward as a reference architecture for canonical cross-chain tokens.
​

They refer to the same standard. xERC-20 was the working name coined by the Connext team when the design was first published informally; ERC-7281 is the formal EIP number assigned when the proposal was submitted to the Ethereum EIPs repository. Most protocols and documentation use both terms interchangeably. The reference implementation by DeFi Wonderland uses the xERC-20 name in its repository and contract naming.
​

Not necessarily. The lockbox pattern allows existing ERC-20 tokens to remain live. A lockbox contract wraps the original token address and exposes xERC-20 mint and burn interfaces to authorized bridges. Users holding the original token address are unaffected; bridges migrated to the xERC-20 system interact through the lockbox while the canonical token address stays unchanged for wallets and protocols.
​

Yes. The ERC-7281 registry is controlled by the token issuer (or a governance contract the issuer designates). The issuer can set a bridge's maxLimit to zero, which prevents any further minting from that bridge address immediately. Outstanding tokens already minted by that bridge remain valid; the rate limit governs future issuance only, not existing supply already in circulation.
​

The currentLimit regenerates over a configurable time window set by the issuer at bridge registration time. The DeFi Wonderland reference implementation uses a 24-hour rolling window by default, meaning a bridge that reaches its daily mint cap regains full capacity after 24 hours without a governance transaction. Issuers can set different window durations per bridge depending on risk tolerance and expected transfer volume.
​

Eco's routing layer executes stablecoin transfers across 15 chains by selecting among authorized bridge paths and settlement routes. For stablecoins that implement ERC-7281, Eco's bridge-selection logic respects the token's authorized bridge set, the same set the issuer has configured with rate limits. This means Eco can route through any bridge the issuer has explicitly authorized in the xERC-20 registry, inheriting the issuer's security guarantees automatically. See blockchain bridge fundamentals for more on how bridge selection works.
​

Sources and methodology. ERC-7281 specification verified against the Ethereum EIPs repository. Reference implementation reviewed from the DeFi Wonderland xERC-20 repository. Bridge exploit figures sourced from Rekt.news bridge hack leaderboard and cross-referenced with Chainalysis 2024 bridge security report. EIP review status verified April 2026. Adoption commentary based on protocol governance documentation and GitHub discussion threads.
​

Teams building cross-chain stablecoin payment infrastructure can explore how Eco's routing layer handles multi-bridge token flows and authorized bridge selection at eco.com.
​