Names and addresses
Blockchains use addresses to identify external actors through a hash of a public key. On-chain addresses are represented using a concise, immutable binary format, typically 20 or 32 bytes long, often derived from a hashing function. However, there are various human-readable representations of these binary addresses that are displayed to clients.
Below are examples of two different address formats:
- Bech32: bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9
- Checksummed Hex: 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed
Addr
Addresses in the Cosmos SDK are 20-character long strings and include security checks, such as chain-prefix in Bech32, checksums in Bech32, and checksummed hex (EIP55). Since CosmWasm is an extension of the Cosmos SDK, it adheres to the same address rules; wallets, smart contracts, and modules each have an identifier address with a specific prefix. For instance, "archway1..." is used for Archway, while "wasm1..." is used for some CosmWasm-enabled chains.
When providing an address to smart contracts, you can submit it as a string and subsequently validate the input as an Addr. The Addr serves as a wrapper for a plain string, offering valuable utility functions such as address validation through string validation.
There is also a more uncommon representation of an address, called a Canonical Address, which is the binary representation used internally in the blockchain. This representation can be used for all storage lookups, and its format can be converted into multiple types of string addresses.
To better understand Canonical Addresses, we can think about Bitcoin transitioning from Base58 to Bech32 encoding, along with SegWit: once the encoding changes, message.signer would lose access to their own account. Canonical Addresses provide us with a stable identifier to work with.
Naming
We can consider names as a form of address, albeit one that requires a contract query (with storage access) to resolve. It cannot be resolved merely by calling a pure function.
