# 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

<figure><img src="https://180242877-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJvtfR7L0PJEmCLLFDuzx%2Fuploads%2Fd9vt4QjHVc5Um5Qi0jQ3%2FxSPACE%20Bridge%20Map.png?alt=media&#x26;token=98bc039f-2377-4e1d-8fd8-983ab9554c94" alt=""><figcaption><p>Native SPACE is bridged across chains via Hyperlane go through this flow</p></figcaption></figure>

#### 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.&#x20;

***

### 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 <a href="#f4a1" id="f4a1"></a>

Comparative Table between ***xERC20*** and ***any Token*** Standards

<figure><img src="https://miro.medium.com/v2/resize:fit:1400/1*AFCq9dtU_dbudM3xUZc2oA.png" alt="" height="411" width="700"><figcaption><p>source: <a href="https://www.xerc20.com/">https://www.xerc20.com</a></p></figcaption></figure>

### Glossary

* **SPACE (canonical):** the native token on the canonical chain.
* **xSPACE:** the official xERC20 representation of SPACE deployed on supported chains.&#x20;
* **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.

***