The Problem: Token Fragmentation
In traditional blockchain ecosystems with EVM support, tokens often exist in multiple representations:- Native tokens in the base blockchain format
- Wrapped tokens as ERC20 contracts
- IBC vouchers for cross-chain assets
- Bridge tokens from various bridge protocols
Single Token Representation v2 (STRv2)
STRv2 solves fragmentation by ensuring each asset has exactly one canonical representation that automatically adapts to its usage context.Core Principles
One Asset, One Representation Each token exists in either Cosmos or EVM format at any given time, never both simultaneously. The representation automatically switches based on where it’s being used. Automatic Conversion When tokens move between Cosmos and EVM contexts, conversion happens transparently:- Sending to an Ethereum address → converts to ERC20
- Sending to a Cosmos address → converts to native coin
- IBC transfer with EVM recipient → arrives as ERC20
Token Pairs: The Bridge
A TokenPair links a Cosmos denomination with an ERC20 contract address, establishing the canonical mapping:Origin Types
Native Cosmos Coins- Start as Cosmos SDK coins (test, uosmo, etc.)
- Module deploys an ERC20 contract representation
- Contract owned by module (OWNER_MODULE)
- Conversions use mint/burn mechanism
- Start as deployed ERC20 contracts
- Module creates a Cosmos coin denomination
- Contract owned externally (OWNER_EXTERNAL)
- Conversions use escrow/release mechanism
Precompiled Contracts: The Magic
Traditional wrapped tokens require expensive contract storage and logic. STRv2 uses precompiled contracts - native code that appears as ERC20 to the EVM but executes at native speed.Native Precompiles
For Cosmos-native assets, precompiles provide:- Standard ERC20 interface (transfer, approve, balanceOf)
- Direct bank module integration
- No contract storage overhead
- Gas costs 10-100x lower than regular ERC20
Dynamic Precompiles
For advanced functionality:- WERC20 interfaces with deposit/withdraw
- Custom extensions per token
- Runtime registration
- Module-specific features
Conversion Mechanics
Cosmos → ERC20
When converting native coins to ERC20:- User initiates conversion via message or automatic trigger
- Module validates token pair is enabled
- Coins escrowed in module account (removed from circulation)
- ERC20 minted to recipient address
- Event emitted for tracking
ERC20 → Cosmos
When converting ERC20 to native coins:- User initiates conversion or automatic trigger
- Module validates sufficient ERC20 balance
- Tokens burned (if module-owned) or escrowed (if external)
- Coins released from module account
- Event emitted for tracking
IBC Integration
STRv2 seamlessly integrates with IBC transfers through middleware:Automatic Conversion
When receiving IBC tokens:- If recipient is Ethereum address → convert to ERC20
- If recipient is Cosmos address → keep as native
- If token pair doesn’t exist → create dynamically
Cross-Chain DeFi
This enables powerful workflows:- Receive OSMO from Osmosis via IBC
- Automatically converts to ERC20
- Use in Uniswap-style DEX
- Swap for other tokens
- Send back via IBC as native
Design Rationale
Why Not Simple Wrapping?
Traditional wrapping (like WETH) has drawbacks:- Double tokens: Native ETH and WETH coexist
- Manual process: Users must wrap/unwrap
- Liquidity split: Separate pools for each version
- Gas overhead: Extra contract calls
Why Precompiles?
Precompiles provide:- Native speed: Direct state access
- Compatibility: Standard ERC20 interface
- Efficiency: No storage overhead
- Transparency: Appears as regular token to contracts
Why Automatic Conversion?
Automatic conversion improves UX:- No manual steps: Tokens “just work”
- Unified liquidity: Single pool per asset
- Reduced errors: No wrong token mistakes
- Better bridging: Seamless cross-chain
Security Considerations
Supply Integrity
The total supply remains constant across conversions:Ownership Models
Module Ownership (Native Coins):- Module can mint/burn ERC20
- Ensures 1:1 backing
- No external control risks
- Original deployer retains control
- Module uses escrow mechanism
- Preserves contract upgradeability
Attack Vectors
Malicious ERC20 Contracts- Validation before registration
- Event log verification
- Balance checks pre/post operation
- State changes before external calls
- Checks-effects-interactions pattern
- Gas limit enforcement
Benefits for Users
Simplified Experience
- One token to rule them all
- No manual wrapping
- Automatic conversion where needed
- Consistent balance across contexts
Better Capital Efficiency
- No liquidity fragmentation
- Single market per asset
- Lower slippage
- Unified order books
Enhanced Composability
- Use any token in any context
- Seamless DeFi integration
- Cross-chain applications
- Future-proof design
Benefits for Developers
Easier Integration
- Standard interfaces everywhere
- No wrapper contract management
- Automatic handling
- Less code complexity
Gas Optimization
- Native precompile efficiency
- No extra contract calls
- Batched operations
- Lower user costs
Innovation Enablement
- Build cross-VM applications
- Leverage both ecosystems
- New DeFi primitives
- Unified token standards
Future Evolution
Potential Enhancements
Multi-VM Support- CosmWasm integration
- Move VM compatibility
- Universal token representation
- Streaming payments
- Programmable transfers
- Conditional conversions
- Batch operations
- IBC native tokens
- Universal asset IDs
- Metadata preservation
- Governance coordination