Transactions, Messages, and Queries

In the previous section, you learned that accounts authorize activity on a chain using digital signatures and sequence numbers. Accounts provide identity and permission, but transactions are the actual mechanism that authorizes and executes logic on the chain.

Interacting with a chain

A Cosmos SDK blockchain is a deterministic state machine. Its state changes only when transactions are executed and committed in blocks.

Users and applications interact with the blockchain in two fundamental ways:

• Transactions modify state and are included in blocks. When a user wants to change something (transfer tokens, delegate stake, submit a governance proposal), they submit a transaction.
• Queries read state and are not included in blocks. When a user wants to inspect something (check a balance, view delegations, read proposal details), they perform a query.

Only transactions affect consensus state.

Transactions

A transaction is a signed container that carries one or more actions to be executed on the blockchain.

A transaction includes:

• Messages: one or more actions you want to execute (send tokens, delegate stake, vote on a proposal)
• Signatures: cryptographic proof that you authorize these actions
• Sequence number: prevents someone from resubmitting your transaction (replay protection)
• Gas limit: the maximum computational resources you’re willing to spend
• Fees: what you pay for the transaction to be processed

The transaction itself does not define business logic. Instead, it packages intent (messages) to change state, proves authorization (signatures), and specifies execution limits (gas and fees). You can think of a transaction as an envelope you send to the blockchain, with a message inside containing instructions, a signature to prove authenticity, and a stamp to pay for postage.

Transaction
  ├── Message 1
  ├── Message 2
  ├── ...
  ├── Signature(s)
  ├── Sequence
  ├── Gas limit
  └── Fees

In the Cosmos SDK, account metadata and transaction authorization are handled by the x/auth module. Transaction construction and encoding are configured through the SDK’s transaction system (commonly via x/auth/tx).

Messages

A message (sdk.Msg) is the actual instruction inside a transaction. Each message is defined by a specific module and represents a single action. Messages are located in that module’s types package (like x/bank/types or x/staking/types). Modules define which messages they support and the rules for executing them. While the transaction provides the envelope with signatures and fees, the message defines the specific action to execute.

Examples include MsgSend (transfer tokens), MsgDelegate (delegate stake), and MsgVote (vote on proposals).

If a transaction contains multiple messages, they execute in order. See Message execution and atomicity below for details.

How messages are defined

Messages in the Cosmos SDK are defined in each module’s tx.proto file using Protocol Buffers (protobuf), which provides deterministic serialization, backward compatibility, and cross-language support. Each message is defined in a .proto file that specifies its fields, data types, and unique identifiers. From this schema, code is generated that allows the message to be constructed, serialized, and validated.

Here’s an example of a transaction in JSON format:

{
  "body": {
    "messages": [
      {
        "@type": "/cosmos.bank.v1beta1.MsgSend",
        "from_address": "cosmos1...",
        "to_address": "cosmos1...",
        "amount": [{"denom": "uatom", "amount": "1000000"}]
      }
    ],
    "memo": "",
    "timeout_height": "0",
    "extension_options": [],
    "non_critical_extension_options": []
  },
  "auth_info": {
    "signer_infos": [
      {
        "public_key": {
          "@type": "/cosmos.crypto.secp256k1.PubKey",
          "key": "A..."
        },
        "mode_info": {"single": {"mode": "SIGN_MODE_DIRECT"}},
        "sequence": "0"
      }
    ],
    "fee": {
      "amount": [{"denom": "uatom", "amount": "500"}],
      "gas_limit": "200000",
      "payer": "",
      "granter": ""
    }
  },
  "signatures": ["MEUCIQDx..."]
}

This transaction transfers 1 ATOM (1,000,000 uatom) from one account to another. You can see the message in the body.messages array, the sender’s public key and sequence in auth_info.signer_infos, the fee and gas limit in auth_info.fee, and the cryptographic signature in the signatures array.

When broadcast, this JSON is serialized into bytes using protobuf, ensuring every validator interprets the transaction identically.

Message execution and atomicity

When a transaction contains multiple messages, they are executed in the order they appear in the transaction.

For example, a transaction might:

1. Send tokens to another account.
2. Delegate those tokens to a validator.

If the order were reversed, the delegation could fail due to insufficient balance.

At execution time, messages inside a transaction are applied sequentially. The transaction succeeds only if all messages execute successfully.

Conceptually:

Transaction
  ├── Msg 1 → execute
  ├── Msg 2 → execute
  ├── Msg 3 → execute

If any message fails, the transaction returns an error and none of the message execution writes from that transaction are committed.

Message execution inside a transaction is atomic: all messages commit or none do. The transaction lifecycle page covers this execution pipeline in more detail.

In v0.53, transactions support an optional unordered mode. When unordered=true, the normal per-signer sequence check is bypassed and replay protection is handled through timeout_timestamp plus unordered nonce tracking in x/auth. This enables fire-and-forget and concurrent transaction submission without coordinating sequence numbers. Unordered transactions must have a timeout_timestamp set and a sequence of 0. For how clients build and submit them, see Generating an Unordered Transaction.

Blocks and transactions

A blockchain can be understood as a sequence of blocks. Each block contains an ordered list of transactions.

When a new block is committed:

1. Each transaction in the block is applied to the current state.
2. Each transaction executes its messages in order.
3. Modules update their portion of state.
4. The resulting state becomes the starting point for the next block.

Conceptually:

State₀
  ↓ apply Block 1 (Tx₁, Tx₂, Tx₃)
State₁
  ↓ apply Block 2 (Tx₄, Tx₅)
State₂
  ↓ apply Block 3 (...)
State₃

In this way, the blockchain is a deterministic sequence of state transitions driven entirely by transactions.

Blocks group transactions, transactions drive execution, and execution updates state.

Queries

A query retrieves data from the blockchain’s state without modifying it.

Queries are read-only. They don’t require signatures, aren’t included in blocks, and don’t affect consensus state. Modules define query services using protobuf, exposed over gRPC and REST.

For example:

• Query an account’s balance (the x/bank module)
• Query staking delegations (the x/staking module)
• Query governance proposal details (the x/gov module)

Transaction and query flow

Transaction Flow	Query Flow
User ↓ signs Transaction ↓ contains Message(s) ↓ handled by Module(s) ↓ update State	User ↓ Query ↓ Module ↓ State (read-only)

Transactions modify the blockchain. Messages define what modifications occur. Modules execute those modifications in order. Queries allow anyone to observe the resulting state.

The next section, Transaction Lifecycle, follows a transaction from broadcast through validation, block inclusion, execution, and state commitment to show how these components work together in practice.