Skip to main content
In Cosmos SDK Architecture, you learned that transactions change state and must be signed and validated. But who creates and signs these transactions? The answer is accounts. Accounts represent identities on a Cosmos SDK chain. They hold balances, authorize transactions with digital signatures, and prevent transaction replay using sequence numbers. Accounts are managed by the auth module (x/auth), which tracks account metadata like addresses, public keys, account numbers, and sequence numbers. Every account is controlled by a cryptographic keypair derived from a seed phrase. A seed phrase yields one or more private keys, each of which produces a public key and an account address.

​
What is an account

An account is an on-chain identity used to authorize transactions. Each account stores an address, a public key, an account number, and a sequence number, as defined by BaseAccount in the x/auth module: 
type BaseAccount struct {
    Address       string     `protobuf:"bytes,1,opt,name=address,proto3" json:"address,omitempty"`
    PubKey        *anypb.Any `protobuf:"bytes,2,opt,name=pub_key,json=pubKey,proto3" json:"pub_key,omitempty"`
    AccountNumber uint64     `protobuf:"varint,3,opt,name=account_number,json=accountNumber,proto3" json:"account_number,omitempty"`
    Sequence      uint64     `protobuf:"varint,4,opt,name=sequence,proto3" json:"sequence,omitempty"`
}
Accounts can be used in other modules to associate on-chain state with an identity. For example, the bank module (x/bank) maps account addresses to token balances, and the staking module maps them to delegations. The private key and seed phrase are never stored on-chain; they are kept locally by the user or wallet. An account does not execute logic itself; instead, it authorizes transactions. Balance changes for accounts are handled by the modules that process the transaction’s messages. An account’s sequence number is used for replay protection during transaction processing.

​
Public and private keys

Accounts are rooted in cryptographic keypairs. Cosmos SDK uses asymmetric cryptography, where a private key and public key form a pair. This is a fundamental concept in cryptography and is used to secure data and transactions.
  • A private key is used to sign transactions. Before signing, the transaction data is serialized and hashed; the private key then produces a digital signature over this hash. This signature proves ownership of the private key without revealing it. Private keys must always remain secret.
  • A public key is derived mathematically from the private key. The network uses it to verify signatures produced by the corresponding private key. Because the public key is derived through a one-way function, it is not possible to derive the private key from the public key.

​
Seed phrases

Most wallets do not generate raw private keys directly. Instead, they start from a seed phrase (mnemonic), a list of human-readable words such as: 
apple maple river stone cloud frame picnic ladder jungle orbit solar velvet
A private key is then derived from the seed phrase using a deterministic algorithm. Cosmos wallets follow common standards such as: From the seed phrase, a binary seed is computed and used to derive a master private key. From that master key, specific private keys are derived along a path (for example: m/44'/118'/0'/0/0, where 118 is the Cosmos coin type). Each private key produces a public key. Control of the seed phrase means control of the derived private keys and therefore control of the corresponding accounts. Losing the seed phrase without backing it up means losing access to the account forever.

​
Addresses

An address is a shortened identifier derived from the public key. The public key is hashed and encoded, typically in Bech32 format, with a prefix that indicates the chain, for example cosmos. This address is what users share and what appears in state and transactions: 
cosmos1qnk2n4nlkpw9xfqntladh74er2xa62wgas7mv0
An address is not the same as a public key. Because an address is only a hash of the public key, users can generate addresses and receive funds entirely offline. The public key is revealed on-chain the first time the account signs a transaction, at which point validators can verify the signature and the chain stores the public key alongside the account metadata. 
Seed Phrase
    ↓ (BIP-39/BIP-32/BIP-44)
Private Key (secp256k1)
    ↓ (elliptic curve math)
Public Key
    ↓ (hash + Bech32 encoding)
Address

​
Sequences and replay protection

There are two types of transactions in the Cosmos SDK: ordered and unordered. Ordered transactions are the default. Each account tracks a sequence number starting at zero that increments with each transaction. The network rejects any transaction whose sequence number does not match the current value, preventing replay attacks and ensuring that dependent transactions from the same account execute in order (for example, sending tokens then immediately staking them). Unordered transactions bypass this check and use a timeout-based mechanism instead. Example: 
Initial state:
  sequence = 0

After first accepted transaction:
  sequence = 1

After second accepted transaction:
  sequence = 2
If a signed transaction carries sequence = 1 but the account’s current sequence is 2, the transaction is rejected, ensuring that ordered transactions are applied in order and cannot be reused. The Cosmos SDK also supports optional unordered transactions, which allow transactions from the same account to be submitted and processed without strict sequence ordering. When a chain enables unordered transactions, replay protection uses a timeout timestamp and unordered nonce tracking instead of the normal per-signer sequence check. See Transactions, Messages, and Queries for more information.

​
Balances

Accounts are associated with token balances stored on-chain. Balances are managed by the bank module (x/bank) and indexed by account address. While account metadata (address, public key, sequence number) is stored in the auth module’s state, token balances are stored separately in the bank module’s state. When tokens are sent from one account to another, the bank module updates balances in state. Conceptually, a token transfer decreases the sender’s balance and increases the recipient’s balance. An account must have sufficient balance to cover the tokens being sent and any associated transaction fees. If the balance is insufficient, the transaction is rejected during validation.

​
Types of accounts

Cosmos SDK supports several account types that extend the base account model:
  • Base account: A standard account that holds balances and signs transactions. This is the most common account type for users.
  • Module account: Owned by a module rather than a user. Module accounts are derived from the module name and cannot be controlled by a private key. For example, the staking module uses a module account to hold all delegated tokens, and the distribution module uses a module account to hold rewards before they are distributed. This design allows protocol logic to custody tokens without requiring a private key holder, which is essential for decentralized operations.
  • Vesting account: Holds tokens that unlock gradually over time according to a schedule. Vesting accounts are often used for team allocations or investor tokens that vest over months or years. They restrict spending to only unlocked tokens while still allowing the account to participate in staking and governance.
All account types rely on the same key and address structure but may impose additional rules on balance usage.

​
Accounts and transaction authorization

Accounts authorize transactions by producing digital signatures. A transaction includes:
  • One or more messages
  • A signature created using the private key
  • A sequence number
  • Associated fees
When a transaction is signed, the transaction bytes are serialized and hashed. The private key then generates a digital signature over that hash. This signature proves that the holder of the private key approved the transaction, without revealing the private key itself. During execution of a standard ordered transaction:
  1. The signature is verified using the account’s public key.
  2. The sequence number is checked against the account’s current sequence.
  3. Fees are deducted from the account’s balance.
  4. If validation passes, messages execute and may update state.
  5. If execution succeeds, the sequence number increments and state updates are committed.
High-level flow: 
Seed Phrase
    ↓
Private Key
    ↓ signs
Transaction
    ↓ verified with
Public Key
    ↓ identifies
Address
    ↓ updates
State
Accounts provide identity and authorization, transactions carry intent, and modules execute the logic. The result is stored in state.

​
Summary

Accounts are the foundation of user interaction with a Cosmos SDK chain. They connect cryptographic keys to on-chain identity, authorize transaction execution, and prevent replay attacks. Understanding keys, addresses, balances, and sequence numbers provides the basis for understanding how transactions flow through the system. The next page, Transactions, Messages, and Queries, explains how accounts authorize the actions a transaction carries.