Draft ERC (xERC20) extending ERC-20 so token issuers — not bridges — control which bridges can mint/burn the canonical token, with per-bridge rate-limited burn and mint caps. Solves the fragmentation, security, and liquidity-bootstrap problems of traditional lock-and-mint bridged representations.
- 01canonical multi-chain token issuance
- 02bridge-agnostic token deployments
- 03per-bridge rate limiting
- 04lockbox-wrapped existing ERC-20s
- 05zero-slippage cross-chain transfers
- forge install defi-wonderland/xERC20
- pnpm add @defi-wonderland/xerc20
- pnpm add @openzeppelin/contracts
Implement `IXERC20` on top of ERC-20 with `mint(address to, uint256 amount)` and `burn(address from, uint256 amount)` callable only by approved bridges, plus `setLimits(address bridge, uint256 mintingLimit, uint256 burningLimit)` gated by the token owner. Expose view helpers `mintingMaxLimitOf(bridge)`, `mintingCurrentLimitOf(bridge)`, `burningMaxLimitOf(bridge)`, and `burningCurrentLimitOf(bridge)` that return the per-day max and the linearly-replenishing remaining capacity. For pre-existing ERC-20s, deploy an `XERC20Lockbox` that wraps deposits 1:1 into the xERC20 on the home chain so bridges burn/mint the wrapper and the canonical token stays untouched. Use the `XERC20Factory` to deploy with deterministic CREATE2 addresses across chains so the same bridge config works everywhere.
- ⚑Per-bridge mint/burn limits replenish linearly over a 24-hour duration — setting a fresh limit resets the current usage, which can be exploited by an owner mid-attack; gate `setLimits` behind a timelock or multisig.
- ⚑If `mintingCurrentLimitOf(bridge) == 0` and a user tries to bridge in, the call reverts — front-ends MUST check available capacity before submitting and surface a clear 'bridge cap reached, try later' state.
- ⚑A compromised bridge can drain up to its `mintingLimit` instantly — set conservative caps proportional to the bridge's risk profile, not to expected volume.
- ⚑The Lockbox is single-chain — there must be exactly one home chain holding the canonical ERC-20; deploying lockboxes on multiple chains breaks the 1:1 invariant and lets value double-spend.
- ⚑Bridges that transfer to the bridge contract (instead of calling burn directly) require the xERC20 to detect inbound transfers and auto-burn — most reference implementations don't do this; pick `mint/burn`-callback-style bridges (Connext, Hyperlane, LayerZero adapters).
- ⚑ERC-7281 is Draft — function selectors and event names have shifted across revisions; pin to a specific commit of `defi-wonderland/xERC20` rather than tracking master.