ERC-7281: Sovereign Bridged Tokens (xERC20)
Every "bridged" token you hold has a quiet structural problem underneath it. When a project takes its ERC-20 to a second chain, it almost always hands the keys to a bridge. That bridge mints the representation, controls its supply, and effectively becomes the issuer of "your" token on that chain. It works right up until the bridge gets hacked, and then the wrapped token backing it evaporates. ERC-7281: Sovereign Bridged Tokens, far better known as xERC20, flips that power dynamic. It does not try to build a safer bridge. Instead, it gives token issuers a standard, minimal way to keep ownership of their token on every chain, choose which bridges may mint it, and cap how much damage any single bridge can ever do. It aims to do for cross-chain token issuance what ERC-20 did for tokens themselves.
TL;DR
Why Are Bridged Tokens So Fragile?
ERC-20 was designed to live on exactly one chain. It has no concept of minting across chains and no awareness that other networks even exist. So when a project wants its token on another Layer-2, a bridge steps in, and the usual approaches both create problems.
The wrapped token trap. In the dominant "lock-and-mint" model, a bridge locks the canonical token on the home chain and mints a representation on the destination. That representation belongs to the bridge. If two bridges serve the same chain, they each mint their own incompatible version, and the two are not fungible.
The spec illustrates the trap simply. Alice bridges 100 USDT through Bridge 1, which locks 100 on L1 and mints 100 on L2. Bob bridges 100 through Bridge 2, same thing. Bob now holds 200 on L2. But when Bob tries to withdraw all 200 through Bridge 2, it fails, because Bridge 2 only ever locked 100. The moment liquidity spreads across bridges, true fungibility breaks.
The sovereignty problem. When a bridge deploys and controls the token contract on a destination chain, the issuer permanently loses control of that representation. The project that created the asset is no longer the logical owner of its own token on that chain.
Uncapped, concentrated risk. Because the bridge custodies all the backing for the supply it minted, a single bridge compromise can render the entire bridged supply worthless. There is no circuit breaker. The trigger for xERC20 was exactly this: on July 6, 2023, the Multichain bridge collapsed. Chainalysis reported losses above $125 million, with nearly $120 million drained from Multichain's Fantom bridge alone. The incident was tied to the detention of Multichain's CEO, who, despite claims of decentralization, held sole control over the keys. Bridges accounted for more than half of all crypto stolen from DeFi in 2022.
What Is ERC-7281?
ERC-7281 came directly out of the pain of watching bridged tokens get wiped out.
How Does ERC-7281 Work?
The elegance of xERC20 is how little it adds. Every xERC20 is still a fully compliant ERC-20, with just enough new surface area to move control from the bridge to the issuer.
The IXERC20 interface
interface IXERC20 {
// Owner (the token issuer) sets a bridge's mint & burn limits
function setLimits(address _bridge, uint256 _mintingLimit, uint256 _burningLimit) external;
// Only an approved bridge can call these
function mint(address _user, uint256 _amount) external;
function burn(address _user, uint256 _amount) external;
// How much can this bridge mint/burn right now?
function mintingCurrentLimitOf(address _bridge) external view returns (uint256);
function burningCurrentLimitOf(address _bridge) external view returns (uint256);
function setLockbox(address _lockbox) external;
}
The rules are simple. The mint and burn functions can only be called by a bridge the issuer has approved, and each call checks against that bridge's available limit first. The setLimits and setLockbox functions can only be called by the owner. This keeps supply management inside the token contract, so once a burn-and-mint completes, the bridge has no continuing custody of the asset. Standard ERC-20 has no mint or burn in its spec at all; xERC20 exposes controlled, per-bridge-permissioned versions, each governed by a rate limit.
Rate limits: the circuit breaker
Each approved bridge gets a maximum limit and a refill rate, in each direction. The available limit regenerates linearly until it hits the maximum, like a leaky bucket.
struct BridgeParameters {
uint256 timestamp; // last time the limit was used
uint256 ratePerSecond; // how fast the limit refills
uint256 maxLimit; // the ceiling
uint256 currentLimit; // available right now
}
In defi-wonderland's reference implementation, a limit fully replenishes over one day by default. The maximum loss from a compromised bridge is capped at its rate limit, and if a bridge is exploited, the issuer calls setLimits(bridge, 0, 0) to cut it off instantly.
The Lockbox
How does a token already live on Ethereum adopt this without redeploying everything? Through the Lockbox, which behaves just like WETH.
interface IXERC20Lockbox {
function deposit(uint256 _amount) external; // lock ERC-20, get xERC20 1:1
function withdraw(uint256 _amount) external; // burn xERC20, get ERC-20 back
}
Because all home-chain liquidity now sits in a single Lockbox shared across every approved bridge, there is exactly one fungible representation per chain. One honest open problem remains: there is no permissionless registry to map an xERC20 across chains, since a spoofed mapping could let an attacker steal from every bridge at once. For now, bridges maintain their own mappings, exactly as they already do.
Why Is ERC-7281 Important?
For a cross-chain DEX aggregator like Rango, the implications are direct.
Who is actually using it?
Adoption is real, if early: Alchemix (xALCX, xalUSD, xalETH), Connext/Everclear's NEXT, Renzo's ezETH (across Arbitrum, Base, Blast, BNB Chain, Linea, Mode, and Optimism), Puffer's pufETH, DappRadar's xRADAR (adopted after Multichain stranded its old bridge), and Beefy's BIFI, plus a long tail of smaller tokens like Kelp DAO's rsETH. Glacis Labs supports xERC20 routing, and Optimism's Token House approved a mission to enable it across the Superchain in February 2024. Not every proposal landed, though: Lido's high-profile push to adopt xERC20 for wstETH stalled and was never put to a vote.
Challenges and Considerations
Conclusion
For years, going multichain meant surrendering control of your token to a bridge and praying it never broke. xERC20 rewrites that deal. By moving mint and burn authority back into the token contract, gating it behind an issuer-controlled allowlist, and wrapping every bridge in a rate limit, it turns a catastrophic, all-or-nothing failure mode into a bounded, recoverable one. The standard is still a draft and the mapping problem is still open, but the core insight, that token issuers should be sovereign over their own assets and no single bridge should be able to drain everything, is exactly what a healthy multichain ecosystem needs.
Resources and Further Readings
Frequently asked questions
Check out most commonly asked questions, addressed based on community needs. Can't find what you are looking for?
Contact us, our friendly support helps!
What is the difference between an ERC-20 and an xERC20?
An xERC20 is a fully compatible ERC-20 with a small extension. It adds permissioned mint and burn functions that only approved bridges can call, plus a per-bridge rate-limiting system the issuer controls. A normal ERC-20 relies entirely on a bridge to handle cross-chain movement; an xERC20 keeps that authority inside the token contract and lends a capped, revocable amount of it to bridges the issuer trusts.
Does xERC20 prevent bridge hacks?
No. It does not make any underlying bridge more secure; it limits the blast radius when one fails. The most an attacker can extract through a compromised bridge is capped at that bridge's current limit, and the issuer can drop a hacked bridge to zero immediately, turning a total-loss scenario into a recoverable one. It pairs well with good Web3 security habits rather than replacing them.
How does xERC20 relate to standards like ERC-7683 or ERC-7786?
They solve different layers. xERC20 standardizes the token and who can mint it across chains. ERC-7683 focuses on cross-chain intents and settlement, while messaging standards like ERC-7786 standardize how contracts talk across chains. LayerZero's OFT, by contrast, bakes a specific bridge's messaging into the token, coupling the asset to that provider. xERC20's defining trait is that it is fully bridge-agnostic.
