在Cosmos 架构中，你已经了解到交易会改变状态，因此必须经过签名和验证。但这些交易是谁创建并签名的？答案就是账户。 账户表示 Cosmos SDK 链上的身份。它们持有余额，使用数字签名授权交易，并通过序列号防止交易重放。账户由 auth 模块（x/auth）管理，该模块会跟踪账户元数据，例如地址、公钥、账户号和序列号。 每个账户都由一对从助记词派生出的加密密钥控制。一个助记词可以生成一个或多个私钥，而每个私钥又会生成对应的公钥和账户地址。

​
什么是账户

账户是用于授权交易的链上身份。每个账户都会存储一个地址、公钥、账户号和序列号，这一点由 x/auth 模块中的 BaseAccount 定义： 
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"`
}
账户还可以被其他模块用来将链上状态与某个身份关联起来。例如，银行模块（x/bank）会将账户地址映射到代币余额，而 staking 模块会将其映射到委托关系。 私钥和助记词永远不会存储在链上；它们由用户或钱包保存在本地。 账户本身不会执行逻辑；它的作用是授权交易。账户余额的变化由处理该交易消息的模块负责。账户的序列号会在交易处理期间用于重放保护。

​
公钥与私钥

账户建立在密码学密钥对之上。Cosmos SDK 使用非对称密码学，其中私钥和公钥构成一对。这是密码学中的基础概念，用于保护数据和交易的安全。
  • 私钥用于对交易签名。签名前，交易数据会先被序列化并哈希；随后私钥会对这个哈希生成数字签名。这个签名可以证明签名者持有该私钥，而无需暴露私钥本身。私钥必须始终保密。
  • 公钥由私钥通过数学方式推导得到。网络使用它来验证对应私钥生成的签名。由于公钥是通过单向函数推导出来的，因此不可能从公钥反推出私钥。

​
助记词

大多数钱包不会直接生成原始私钥，而是从助记词（mnemonic）开始，也就是一组人类可读的单词，例如： 
apple maple river stone cloud frame picnic ladder jungle orbit solar velvet
然后使用确定性算法从助记词派生出私钥。Cosmos 钱包通常遵循以下通用标准： 系统会先从助记词计算出一个二进制种子，再用它派生主私钥。然后再从主私钥沿着特定路径派生具体私钥（例如：m/44'/118'/0'/0/0，其中 118 是 Cosmos 的 coin type）。每个私钥都会生成一个公钥。 掌握助记词，就意味着掌握由它派生出的私钥，也就意味着掌握对应的账户。如果助记词丢失且没有备份，就会永久失去该账户的访问权限。

​
地址

地址是从公钥派生出的缩短标识符。公钥会先被哈希再编码，通常采用 Bech32 格式，并带有表明链类型的前缀，例如 cosmos。这就是用户对外分享、以及出现在状态和交易中的地址： 
cosmos1qnk2n4nlkpw9xfqntladh74er2xa62wgas7mv0
地址并不等同于公钥。由于地址只是公钥的哈希，用户可以在完全离线的情况下生成地址并接收资金。公钥会在账户第一次签名交易时暴露到链上；此时验证者就可以验证签名，而链也会将该公钥与账户元数据一起存储。 
助记词
    ↓ (BIP-39/BIP-32/BIP-44)
私钥 (secp256k1)
    ↓ (椭圆曲线数学)
公钥
    ↓ (哈希 + Bech32 编码)
地址

​
序列号与重放保护

Cosmos SDK 中有两类交易：有序交易和无序交易。有序交易是默认类型。每个账户都会维护一个从零开始的序列号，并在每次交易后递增。网络会拒绝任何序列号与当前值不匹配的交易，从而防止重放攻击，并确保同一账户发出的相互依赖交易按顺序执行（例如先发送代币，再立即进行质押）。无序交易则会跳过这一检查，改用基于超时的机制。 示例： 
初始状态:
  sequence = 0

第一笔交易被接受后:
  sequence = 1

第二笔交易被接受后:
  sequence = 2
如果一笔已签名交易携带 sequence = 1，但该账户当前的序列号是 2，那么这笔交易会被拒绝，从而确保有序交易按顺序应用，且不能被重复使用。 Cosmos SDK 也支持可选的无序交易，这使得同一账户发出的交易可以在不严格依赖序列号顺序的情况下提交和处理。当链启用无序交易时，重放保护会使用超时时间戳和无序 nonce 跟踪机制，而不是常规的按签名者逐个检查序列号。 更多信息请参见交易、消息与查询。

​
余额

账户会关联存储在链上的代币余额。余额由银行模块（x/bank）管理，并通过账户地址建立索引。账户元数据（地址、公钥、序列号）存储在 auth 模块的状态中，而代币余额则单独存储在银行模块的状态中。 当代币从一个账户发送到另一个账户时，银行模块会更新状态中的余额。从概念上讲，一次代币转账会减少发送方余额，并增加接收方余额。 账户必须有足够的余额来覆盖发送的代币数量以及相关交易手续费。如果余额不足，交易会在验证阶段被拒绝。

​
账户类型

Cosmos SDK 支持多种扩展基础账户模型的账户类型：
  • 基础账户：持有余额并签名交易的标准账户。这是用户最常见的账户类型。
  • 模块账户：由模块而不是用户拥有。模块账户由模块名称派生，不能通过私钥控制。例如，staking 模块使用模块账户持有所有已委托代币，distribution 模块使用模块账户在奖励分发前暂存奖励。这种设计使协议逻辑能够在不依赖私钥持有者的情况下托管代币，这对于去中心化运行至关重要。关于如何添加一个用于接收手续费的模块账户的实际示例，可参见完整计数器模块演练中的模块账户。
  • 归属账户：持有按照预定时间表逐步解锁的代币。归属账户通常用于团队分配或按月、按年逐步解锁的投资人代币。它只允许使用已经解锁的代币进行支出，同时仍然允许账户参与质押和治理。
所有账户类型都依赖相同的密钥和地址结构，但可能会对余额使用施加额外规则。

​
账户与交易授权

账户通过生成数字签名来授权交易。 一笔交易包括：
  • 一条或多条消息
  • 使用私钥创建的签名
  • 一个序列号
  • 相关手续费
当交易被签名时，交易字节会先被序列化并哈希。然后私钥会对该哈希生成数字签名。这个签名可以证明私钥持有者批准了该交易，而无需暴露私钥本身。 在标准有序交易的执行过程中：
  1. 使用账户的公钥验证签名。
  2. 检查序列号是否与账户当前序列号一致。
  3. 从账户余额中扣除手续费。
  4. 如果验证通过，则执行消息，并可能更新状态。
  5. 如果执行成功，则递增序列号并提交状态更新。
高层流程： 
助记词
    ↓
私钥
    ↓ 签名
交易
    ↓ 由其验证
公钥
    ↓ 标识
地址
    ↓ 更新
状态
账户提供身份与授权，交易承载意图，模块执行逻辑，最终结果存储在状态中。 要进一步了解 Cosmos 区块链中的交易流程，请访问交易生命周期页面

​
总结

账户是用户与 Cosmos SDK 链交互的基础。它将密码学密钥与链上身份连接起来，授权交易执行，并防止重放攻击。 理解密钥、地址、余额和序列号，是理解交易如何在系统中流转的基础。下一页交易、消息与查询将说明账户如何授权交易所承载的操作。
In Cosmos 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. For a working example of adding a module account to receive fees, see Module accounts in the Full Counter Module Walkthrough.
  • 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. To learn more about the transaction flow in a Cosmos blockchain, visit the Transaction Lifecycle page

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