> ## Documentation Index
> Fetch the complete documentation index at: https://cosmos-docs-sync-security-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Single Token Representation

> Unified token model across Cosmos and EVM ecosystems

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

## Related Documentation

* [ERC20 Module Reference](/evm/latest/documentation/cosmos-sdk/modules/erc20) - Configuration and token pair management
* [Precompiled Contracts](/evm/latest/documentation/smart-contracts/precompiles/overview) - Technical implementation details