​
问题

支持 EVM 的传统区块链生态通常会出现代币碎片化：
  • 基础链原生格式的代币
  • 作为 ERC20 合约存在的封装代币
  • 用于跨链资产的 IBC 凭证
  • 多种桥接代币表示
这会导致流动性分散、用户困惑以及资本配置效率低下。

​
单一代币表示 v2（STRv2）

STRv2 确保每种资产都只有一个规范表示，并且会根据其使用场景自动适配。 核心原则：任意时刻，每个代币只会以 Cosmos 或 EVM 其中一种格式存在，绝不会同时以两种格式存在。其表示会根据使用位置自动切换。 自动转换：
  • 发送到以太坊地址 → 转换为 ERC20
  • 发送到 Cosmos 地址 → 转换为原生代币
  • 向 EVM 接收方发起 IBC 转账 → 资产以 ERC20 形式到账

​
TokenPair

TokenPair 将一个 Cosmos denomination 与一个 ERC20 合约地址关联起来： 
Cosmos Coin (uatom) ←→ TokenPair ←→ ERC20 Contract (0x...)
原生 Cosmos 代币：
  • 初始为 Cosmos SDK coin（uatom、uosmo 等）
  • 模块会部署其对应的 ERC20 合约表示
  • 转换采用 mint/burn 机制
现有 ERC20 代币：
  • 初始为已部署的 ERC20 合约
  • 模块会创建对应的 Cosmos coin denomination
  • 转换采用 escrow/release 机制

​
预编译合约

STRv2 不使用传统的封装代币合约，而是使用预编译合约。这是一种原生代码，在 EVM 看来表现为 ERC20，但以原生速度执行。 原生预编译：
  • 标准 ERC20 接口（transfer、approve、balanceOf）
  • 与 bank 模块直接集成
  • 没有合约存储开销
  • Gas 成本比普通 ERC20 低 10 到 100 倍
动态预编译：
  • 带有 deposit/withdraw 的 WERC20 接口
  • 支持自定义代币的运行时注册
  • 提供模块级特性

​
转换机制

Cosmos → ERC20：
  1. 代币被托管到模块账户
  2. 向接收方铸造 ERC20
ERC20 → Cosmos：
  1. 代币被销毁（若由模块持有）或被托管（若来自外部）
  2. 从模块账户释放对应代币
供应量不变量保持为： 
Total Supply = Cosmos Circulating + ERC20 Circulating + Module Escrow

​
IBC 集成

STRv2 通过中间件与 IBC 集成，并会根据接收方地址类型自动转换：
  • 接收方为以太坊地址 → 转换为 ERC20
  • 接收方为 Cosmos 地址 → 保持为原生形式
  • 缺少 token pair → 动态创建
这使跨链 DeFi 工作流可以无缝衔接：代币可通过 IBC 接收，并可立即在 EVM 合约中使用，无需手动转换步骤。

​
设计理由

为什么不是简单封装？ 传统封装方式（如 WETH）需要手动执行 wrap/unwrap，会把流动性拆分到原生版本与封装版本之间，并且因为额外的合约调用增加 gas 开销。 为什么选择预编译？ 预编译在兼容 ERC20 的同时提供原生执行速度，没有存储开销，并且对合约来说表现得与普通代币一致。这只有在链级集成下才可能实现。 为什么要自动转换？ 自动转换去除了手动步骤，把每种资产的流动性统一到单一池子中，并消除了因使用错误代币表示而产生的用户错误。

​
安全性

模块所有权（原生代币）：模块可以铸造和销毁 ERC20，从而确保 1:1 锚定，且不存在外部控制风险。 外部所有权（ERC20 源资产）：原始部署者保留控制权，模块使用托管机制，从而保留合约可升级性。 校验：ERC20 合约在注册前会经过校验，包括事件日志验证和余额检查。

​
相关文档

​
The Problem

Traditional blockchain ecosystems with EVM support often have token fragmentation:
  • Native tokens in the base blockchain format
  • Wrapped tokens as ERC20 contracts
  • IBC vouchers for cross-chain assets
  • Multiple bridge token representations
This creates liquidity splitting, user confusion, and inefficient capital allocation.

​
Single Token Representation v2 (STRv2)

STRv2 ensures each asset has exactly one canonical representation that automatically adapts to its usage context. Core Principle: Each token exists in either Cosmos or EVM format at any given time, never both. The representation automatically switches based on where it’s being used. Automatic Conversion:
  • Sending to Ethereum address → converts to ERC20
  • Sending to Cosmos address → converts to native coin
  • IBC transfer with EVM recipient → arrives as ERC20

​
Token Pairs

A TokenPair links a Cosmos denomination with an ERC20 contract address: 
Cosmos Coin (uatom) ←→ TokenPair ←→ ERC20 Contract (0x...)
Native Cosmos Coins:
  • Start as Cosmos SDK coins (uatom, uosmo, etc.)
  • Module deploys an ERC20 contract representation
  • Conversions use mint/burn mechanism
Existing ERC20 Tokens:
  • Start as deployed ERC20 contracts
  • Module creates a Cosmos coin denomination
  • Conversions use escrow/release mechanism

​
Precompiled Contracts

Instead of traditional wrapped token contracts, STRv2 uses precompiled contracts - native code that appears as ERC20 to the EVM but executes at native speed. Native Precompiles:
  • Standard ERC20 interface (transfer, approve, balanceOf)
  • Direct bank module integration
  • No contract storage overhead
  • Gas costs 10-100x lower than regular ERC20
Dynamic Precompiles:
  • WERC20 interfaces with deposit/withdraw
  • Runtime registration for custom tokens
  • Module-specific features

​
Conversion Mechanics

Cosmos → ERC20:
  1. Coins escrowed in module account
  2. ERC20 minted to recipient
ERC20 → Cosmos:
  1. Tokens burned (if module-owned) or escrowed (if external)
  2. Coins released from module account
Supply invariant maintained: 
Total Supply = Cosmos Circulating + ERC20 Circulating + Module Escrow

​
IBC Integration

STRv2 integrates with IBC through middleware that automatically converts based on recipient address type:
  • Ethereum address recipient → convert to ERC20
  • Cosmos address recipient → keep as native
  • Missing token pair → create dynamically
This enables seamless cross-chain DeFi workflows where tokens can be received via IBC and immediately used in EVM contracts without manual conversion steps.

​
Design Rationale

Why Not Simple Wrapping? Traditional wrapping (like WETH) requires manual wrap/unwrap steps, splits liquidity between native and wrapped versions, and adds gas overhead from extra contract calls. Why Precompiles? Precompiles provide native execution speed with ERC20 compatibility, no storage overhead, and appear as regular tokens to contracts. This is only possible with chain-level integration. Why Automatic Conversion? Removes manual steps, unifies liquidity into single pools per asset, and eliminates user errors from using wrong token representations.

​
Security

Module Ownership (native coins): Module can mint/burn ERC20, ensuring 1:1 backing with no external control risks. External Ownership (ERC20 origin): Original deployer retains control, module uses escrow mechanism, preserving contract upgradeability. Validation: ERC20 contracts validated before registration with event log verification and balance checks.