# 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

Native SPACE is bridged across chains via Hyperlane go through this flow

#### 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

source: https://www.xerc20.com

### 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. *** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.spacetoken.tech/dev-ressources/infrastructure/xerc20.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.