Skip to main content

​
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.