Address Types
The SDK defines three distinct address types, each with its own Bech32 prefix:| Address Type | Bech32 Prefix | Example | Purpose |
|---|---|---|---|
| Account Address | cosmos | cosmos1r5v5sr... | User accounts, balances, transactions |
| Validator Operator Address | cosmosvaloper | cosmosvaloper1r5v5sr... | Validator operator identity, staking operations |
| Consensus Address | cosmosvalcons | cosmosvalcons1r5v5sr... | Validator consensus participation, block signing |
- Account public keys:
cosmospub - Validator public keys:
cosmosvaloperpub - Consensus public keys:
cosmosvalconspub
Supported Key Schemes
The Cosmos SDK supports three key schemes. The choice of scheme affects address length and whether it can be used for transactions or consensus:| Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (CometBFT) | |
|---|---|---|---|---|
secp256k1 | 20 | 33 | yes | no |
secp256r1 | 32 | 33 | yes | no |
tm-ed25519 | — not used — | 32 | no | yes |
secp256k1 is the default for user accounts. secp256r1 is supported as an alternative and produces longer addresses (32 bytes). tm-ed25519 is used exclusively for validator consensus keys and does not produce a user-facing address.
Address Derivation
Addresses are derived from public keys through cryptographic hashing. The process differs based on the key algorithm:Secp256k1 Keys (Account Addresses)
Account addresses use Bitcoin-style address derivation:crypto/keys/secp256k1/secp256k1.go
Ed25519 Keys (Consensus Addresses)
Consensus addresses use truncated SHA-256:crypto/keys/ed25519/ed25519.go
Bech32 Encoding Process
Once address bytes are derived, they’re converted to Bech32 format: Step 1: Convert from 8-bit to 5-bit encodingtypes/bech32/bech32.go
Configuring Bech32 prefixes
Every Cosmos SDK application sets its Bech32 prefixes and SLIP-44 coin type once at startup viasdk.GetConfig(), then seals the config so it cannot be changed at runtime. The defaults (cosmos, cosmosvaloper, etc.) are defined in types/config.go. Chain developers override them before the app starts:
Address Validation
The SDK validates addresses through:- Format validation: Ensures valid Bech32 encoding
- Prefix validation: Confirms correct HRP for address type
- Length validation: Verifies address is exactly 20 bytes when decoded
Module Addresses
Module accounts use deterministic address derivation defined in ADR-028:Validator Address Relationships
A validator has three related addresses:- Operator Address (
cosmosvaloper1...): The validator’s operational identity, derived from the operator’s account key - Consensus Address (
cosmosvalcons1...): Derived from the validator’s consensus public key (Ed25519), used for block signing - Account Address (
cosmos1...): The operator’s account for receiving rewards
Performance: Address Caching
The SDK caches Bech32-encoded addresses to optimize repeated conversions:Address.String() is called, the SDK:
- Checks the LRU cache for the encoded address
- Returns cached value if found
- Otherwise, performs Bech32 encoding and caches the result
Complete Example
Here’s the full pipeline for creating an account address:Related Concepts
- Accounts - Understanding account types and management
- Store - How addresses are used as keys in state storage
- Transactions - How addresses are used in transaction signing