Connext
Connext xERC20 let token issuers set bridge minting limits
Connext xERC20 gave a token contract’s owner or governor authority to set separate bridge minting and burning limits. Those permissions applied to a particular token deployment and bridge address on each chain. Capacity on one chain did not establish capacity elsewhere, and the token tracked minting separately from burning. This was the legacy Connext integration of the xERC20 design associated with ERC-7281. Token configuration and the bridge’s operating status determined different parts of a transfer’s availability.
The short version: A zero bridge maximum required an owner-authorized change, while depleted capacity under a positive maximum could replenish over time.
Who could change a bridge’s limits?
Bridge administration belonged to the owner account on each xERC20 deployment. A governance contract could hold that role. Holding the token in a wallet did not grant administrative authority over its minting permissions.
Only the token contract’s owner could call
setLimits
in the Wonderland reference implementation.
The call identified a bridge address and separate minting and burning maxima. Connext’s setup assigned those permissions to its appropriate core contract on each chain.
An issuer could authorize several bridges against its own token implementation. Each bridge received its own limits. Delisting one bridge did not require replacing the token contract that the other authorized bridges used.
The owner also controlled later changes to those limits. Compromise of that administrative authority could therefore expand a bridge’s permitted issuance, even when the bridge originally received a restrictive configuration.
Separate allowances on each chain
Token contracts stored bridge limits independently on each chain, keyed by the bridge’s calling address. A shared name, symbol or contract address across networks did not merge their state. Crosschain token mappings associated the deployments; each deployment still enforced its own permissions. A burn-and-mint transfer encountered the origin token’s burning controls and the destination token’s minting controls. Successful origin activity alone did not establish destination issuance.
Several authorized bridges could have minting capacity at the same time. Their allowances did not become a single shared pool. An issuer’s exposure therefore involved its active permissions across bridges and chains, together with its ability to change them. A limit on one bridge’s issuance did not establish a fixed ceiling on every possible loss involving the token.
What happened when a bridge used its allowance?
Successful minting or burning consumed the calling bridge’s remaining capacity in the reference rate limiter. Each direction had its own maximum and current allowance, with time replenishing used capacity.
Wonderland’s reference implementation used a one-day replenishment duration. It derived a per-second refill rate from the configured maximum and capped available capacity at that maximum. Elapsed time governed replenishment; the design did not depend on a calendar-midnight reset.
The reference token’s limit checks used
IXERC20_NotHighEnoughLimits
when a requested mint or burn exceeded remaining capacity. The
mintingCurrentLimitOf
and
burningCurrentLimitOf
getters returned capacity after the applicable time-based calculation. Their corresponding maximum-limit getters exposed the configured ceilings.
Further bridge activity could consume capacity while it replenished. The refill duration described token permission, so it supplied no crosschain delivery deadline or promise of available destination funding.
Existing ERC-20 tokens and the Lockbox
A Lockbox connected an existing ERC-20 token to an xERC20 deployment through a wrapper contract. The reference Lockbox paired ERC-20 deposits and xERC20 issuance at a 1:1 ratio. Redemption burned the corresponding xERC20 amount and released the underlying tokens. An issuer could use this arrangement where its existing token required a wrapper, while deploying xERC20 directly on other supported chains.
The configured Lockbox had a separate privilege boundary: the reference token exempted its minting and burning calls from ordinary bridge rate limits. Its conversion mechanism relied on deposited underlying tokens. Zero ordinary bridge limits therefore did not themselves disable the configured Lockbox. Connext’s
LockboxAdapter
supported automatic unwrapping in integrated destination flows; that adapter role differed from authority to change token limits.
Bridge configurations and the effect of waiting
A blocked mint could reflect temporary exhaustion or disabled minting. Reading the selected bridge’s current and maximum minting limits on the affected token distinguished those cases without changing token permissions.
| Bridge configuration | Immediate effect | Effect of waiting |
|---|---|---|
| Nonzero limits with sufficient capacity | Minting and burning could use their separate allowances. | Used capacity replenished up to each maximum. |
| Nonzero maxima with depleted minting capacity | A mint above remaining capacity reverted. | Sufficient replenishment could permit minting again. |
| Zero minting maximum and nonzero burning maximum | Positive minting failed; burning depended on its allowance. | Time did not restore minting permission. |
| Zero burning maximum and nonzero minting maximum | Positive burning failed; minting depended on its allowance. | Time did not restore burning permission. |
| Both maxima set to zero | Positive ordinary bridge minting and burning failed. | Restoring capacity required an owner-authorized limit change. |
| The configured Lockbox followed its separate exemption from ordinary bridge rate limits. | ||
With a positive maximum, a later reading could show sufficient capacity for the intended mint, provided intervening usage had not consumed it. A zero maximum required the owner’s configuration change before positive minting could resume. Capacity alone did not demonstrate that the bridge had completed a pending transfer.
Token permission and Connext integration
Legacy Connext support also required token mappings and asset allowlisting in its network configuration. Its setup separated owner authorization from those integration records. Router liquidity mattered separately for fast transfers, while receiving applications imposed their own execution requirements. Granting a large token limit neither funded a router nor changed message verification.
Legacy support and retained token control
Connext announced its rebrand to Everclear on June 3, 2024, alongside a shift toward liquidity clearing. A legacy bridge sunset notice explicitly excluded xERC20 tokens from its stated impact. Everclear’s later wind-down announcement on May 21, 2026 described its protocol as already sunset. That later operating change meant the earlier exemption could not establish continuing service availability.
The xERC20 design assigned token administration to each deployment’s owner, independently of a particular bridge’s branding. An unchanged limit entry or retained token balance did not establish an operational transfer route. Replenishing capacity could resolve a token-limit block; it could not restart a discontinued bridge service.
Connext xERC20: common questions
Could a token holder increase a bridge limit by approving more tokens?
ERC-20 spending approval did not change the bridge limits that the token owner configured. In the reference implementation, a caller burning another account’s tokens also needed the corresponding spending allowance. Increasing that wallet approval could satisfy the spending requirement, but it could not bypass an insufficient bridge burning limit or grant minting authority.
How did increasing a maximum affect capacity that a bridge had already used?
The reference implementation increased current capacity by the difference between the new and old maximum. It did not erase prior usage. Lowering a maximum subtracted that difference from current capacity, with a floor of zero.
Which units did setLimits accept for minting and burning?
The reference interface accepted integer token amounts in the token’s smallest units. Interpreting those amounts required the deployed token’s decimals. Minting and burning parameters described token quantities, rather than percentages of a wallet balance or currency-denominated values. They also differed from any transaction fee that a bridge charged.
Were xERC20 tokens from different approved bridges interchangeable?
Bridges that delivered tokens from the same issuer-controlled destination contract delivered the same xERC20 asset. Each integration needed the correct token mapping and its own permissions. That arrangement did not automatically make other representations with the same ticker interchangeable, including representations that a canonical bridge deployed separately.
Did issuer-controlled limits eliminate Connext router fees?
Token rate limits did not determine Connext router fees. Legacy routers charged for fronting destination liquidity on fast transfers, independently of the issuer’s minting and burning permissions. A slippage-free token mechanism therefore did not imply that every transfer path had zero fees.