Sending Transactions

The gRPC Services module pages give each transaction message its fields, its signer, and its JSON body. This page covers the envelope those bodies go into. For the model behind messages and transactions, see Transactions, Messages, and Queries.

The envelope

A transaction is a wrapper around one or more messages and includes the information needed to authorize and pay for them:

{
  "body": {
    "messages": [
      {
        "@type": "/cosmos.bank.v1beta1.MsgSend",
        "from_address": "cosmos1...",
        "to_address": "cosmos1...",
        "amount": [{ "denom": "uatom", "amount": "1000000" }]
      }
    ],
    "memo": "",
    "timeout_height": "0",
    "unordered": false,
    "timeout_timestamp": null,
    "extension_options": [],
    "non_critical_extension_options": []
  },
  "auth_info": {
    "signer_infos": [],
    "fee": {
      "amount": [{ "denom": "uatom", "amount": "5000" }],
      "gas_limit": "200000",
      "payer": "",
      "granter": ""
    },
    "tip": null
  },
  "signatures": []
}

The messages array holds exactly what a module page shows under In a transaction. The @type field is the type URL, and it selects the handler. Everything else is envelope, and defaults are correct unless stated otherwise: payer and granter apply to fee grants, unordered and timeout_timestamp to unordered transactions. Several messages can go in one transaction. They execute in order and atomically.

The three steps

Building, signing, and broadcasting are separate operations. Separating them is what allows offline signing. The commands below are the shortest path; Generating, Signing and Broadcasting Transactions covers multisig, offline signing, and the same flow in Go, gRPC, REST, and CosmJS.

# 1. Build
simd tx bank send mykey cosmos1recipient... 1000000uatom \
  --chain-id cosmoshub-4 --node https://your-rpc-endpoint:443 \
  --gas auto --gas-adjustment 1.5 --gas-prices 0.005uatom \
  --generate-only > unsigned.json

# 2. Sign
simd tx sign unsigned.json --from mykey \
  --chain-id cosmoshub-4 --node https://your-rpc-endpoint:443 \
  --output-document signed.json

# 3. Broadcast
simd tx broadcast signed.json --broadcast-mode sync

Signing covers the chain ID, account number, and sequence, which is what binds a signature to one chain and one use. Given a node, sign fetches the account number and sequence itself; offline signing supplies them with --offline --account-number --sequence. The key must control the address in the message’s signer field. The module pages name that field for every message. See Setting up the keyring for managing the keys these commands sign with. Broadcasting returns a transaction hash, not a result. Query for it:

simd query tx <hash>

A code of 0 is success. For what gas measures and how the limit and price above are applied, see Execution Context, Gas, and Events. The API surfaces broadcast directly through cosmos.tx.v1beta1.Service/BroadcastTx on gRPC or POST /cosmos/tx/v1beta1/txs on REST. Both take the signed transaction as bytes, so building and signing still happen first.

Governance-gated messages

Some messages take authority as their signer, meaning the governance module account, which no one holds a key for. They execute only through a passed governance proposal, wrapped in MsgSubmitProposal. See Proposal submission for the deposit and voting periods a proposal has to clear. The module pages flag every one. MsgUpdateParams on each module is the common case. The address the message needs:

grpcurl -plaintext -d '{"name":"gov"}' localhost:9090 \
  cosmos.auth.v1beta1.Query/ModuleAccountByName

The module pages under gRPC Services carry the message list, field tables, signer, and JSON body for every transaction message.

Overview

gRPC Services

REST (gRPC Gateway)

The envelope

The three steps

Governance-gated messages

​The envelope

​The three steps

​Governance-gated messages

​Related

The envelope

The three steps

Governance-gated messages

Related