xERC20
xSPACE and xERC20
xSPACE is the official cross-chain representation of SPACE, built on the xERC20 (ERC-7281) standard. It was introduced to avoid the typical “wrapped token” failure modes (fragmented liquidity, bridge-controlled token contracts, and operational lock-in), especially after incidents like the Multichain collapse that left many bridged assets stuck or illiquid.
In practical terms: SPACE remains the canonical token on its native chain, and xSPACE is the standardized, issuer-controlled token that can exist on multiple chains without relying on a single bridge’s wrapped asset contract.
Why xERC20 exists
Traditional bridging often works like this:
A bridge deploys its own token contract on the destination chain (a “wrapped” version).
Liquidity and usability depend on the bridge’s design and its token’s acceptance.
If that bridge halts, is exploited, or loses keys, the wrapped supply can become stuck, unredeemable, or heavily discounted.
xERC20 changes the model by keeping token contract control with the issuer and granting bridges explicit mint/burn permissions with limits, so you can diversify bridge risk and revoke access if needed.
Core mechanics
1) Lockbox on the canonical chain
On the canonical SPACE chain, a Lockbox contract escrows the underlying token and serves as the anchor for supply integrity. The typical flow is:
Lock SPACE in the lockbox on the origin chain.
Mint xSPACE on the destination chain (by an authorized bridge/module).
When returning, burn xSPACE and unlock SPACE from the lockbox.
2) Bridge permissions and rate limits
xERC20 lets the issuer authorize one or more bridge modules to mint/burn xSPACE, while enforcing:
Who can mint/burn (per bridge/module)
How much can be minted/burned over time (rate limits / caps)
Revocation if a route becomes unsafe or obsolete
This is the main security/operational advantage: you’re not married to one bridge forever.
3) Fungibility and “official token” UX
Because users receive the same official xSPACE contract on the destination chain (not a bridge-specific wrapped asset), the experience is simpler:
less confusion between multiple “SPACE” variants
less liquidity fragmentation across wrappers
and, in many setups, no need to bootstrap deep liquidity purely for bridging UX
Our current bridge stack: Hyperlane
We now use Hyperlane as the primary bridge layer for xSPACE. Hyperlane’s Warp Routes include an xERC20 integration (HypXERC20 / HypXERC20Lockbox) designed specifically to move xERC20 tokens across chains while preserving issuer control and supporting lockbox conversions.
A good way to describe this in your docs:
Hyperlane Warp Routes are the token-bridging application layer.
xERC20 is the token standard that enforces issuer sovereignty, permissions, and limits.
Combined, they provide a modular path to expand to more chains without recreating a new wrapped-asset design each time.
What users should expect
When bridging SPACE ↔ xSPACE:
1:1 peg logic is enforced by lock/unlock + mint/burn accounting.
The destination asset is xSPACE (official contract) rather than a bridge-specific wrapped token.
Bridge risk is managed through issuer-controlled permissions and limits, with the ability to rotate/replace routes over time.
How xERC20 Enhances Cross-Chain Interactions
Comparative Table between xERC20 and any Token Standards
Glossary
SPACE (canonical): the native token on the canonical chain.
xSPACE: the official xERC20 representation of SPACE deployed on supported chains.
xERC20 (ERC-7281): cross-chain token standard with issuer-controlled bridge permissions and limits.
Lockbox: escrow contract anchoring 1:1 backing on the canonical chain.
Warp Route (Hyperlane): Hyperlane’s token-bridging framework; includes xERC20 modules.
Last updated