--- title: "GetBlockWithTxs fetches a block with decoded txs." method: GET path: "/cosmos/tx/v1beta1/txs/block/{height}" tags: ["Service"] --- # GetBlockWithTxs fetches a block with decoded txs. `GET /cosmos/tx/v1beta1/txs/block/{height}` ## Path parameters - `height` string, int64, required ## Query parameters - `pagination.key` string, byte - `pagination.offset` string, uint64 - `pagination.limit` string, uint64 - `pagination.countTotal` boolean - `pagination.reverse` boolean ## Response `200` A successful response. - CosmosTxV1beta1GetBlockWithTxsResponse — GetBlockWithTxsResponse is the response type for the Service.GetBlockWithTxs method. - `txs` CosmosTxV1beta1Tx[] — txs are the transactions in the block. - `body` CosmosTxV1beta1TxBody — TxBody is the body of a transaction that all signers sign over. - `messages` GoogleProtobufAny[] — messages is a list of messages to be executed. The required signers of those messages define the number and order of elements in AuthInfo's signer_infos and Tx's signatures. Each required signer address is added to the list only the first time it occurs. By convention, the first required signer (usually from the first message) is referred to as the primary signer and pays the fee for the whole transaction. - `@type` string — A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. As of May 2023, there are no widely used type server implementations and no plans to implement one. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. - `memo` string — memo is any arbitrary note/comment to be added to the transaction. WARNING: in clients, any publicly exposed text should not be called memo, but should be called `note` instead (see https://github.com/cosmos/cosmos-sdk/issues/9122). - `timeoutHeight` string, uint64 — timeout_height is the block height after which this transaction will not be processed by the chain. - `unordered` boolean — unordered, when set to true, indicates that the transaction signer(s) intend for the transaction to be evaluated and executed in an un-ordered fashion. Specifically, the account's nonce will NOT be checked or incremented, which allows for fire-and-forget as well as concurrent transaction execution. Note, when set to true, the existing 'timeout_timestamp' value must be set and will be used to correspond to a timestamp in which the transaction is deemed valid. When true, the sequence value MUST be 0, and any transaction with unordered=true and a non-zero sequence value will be rejected. External services that make assumptions about sequence values may need to be updated because of this. - `timeoutTimestamp` string, date-time — timeout_timestamp is the block time after which this transaction will not be processed by the chain. Note, if unordered=true this value MUST be set and will act as a short-lived TTL in which the transaction is deemed valid and kept in memory to prevent duplicates. - `extensionOptions` GoogleProtobufAny[] - `@type` string — A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. As of May 2023, there are no widely used type server implementations and no plans to implement one. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. - `nonCriticalExtensionOptions` GoogleProtobufAny[] - `@type` string — A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. As of May 2023, there are no widely used type server implementations and no plans to implement one. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. - `authInfo` CosmosTxV1beta1AuthInfo — AuthInfo describes the fee and signer modes that are used to sign a transaction. - `signerInfos` CosmosTxV1beta1SignerInfo[] — signer_infos defines the signing modes for the required signers. The number and order of elements must match the required signers from TxBody's messages. The first element is the primary signer and the one which pays the fee. - `publicKey` GoogleProtobufAny — `Any` contains an arbitrary serialized protocol buffer message along with a URL that describes the type of the serialized message. Protobuf library provides support to pack/unpack Any values in the form of utility functions or additional generated methods of the Any type. Example 1: Pack and unpack a message in C++. Foo foo = ...; Any any; any.PackFrom(foo); ... if (any.UnpackTo(&foo)) { ... } Example 2: Pack and unpack a message in Java. Foo foo = ...; Any any = Any.pack(foo); ... if (any.is(Foo.class)) { foo = any.unpack(Foo.class); } // or ... if (any.isSameTypeAs(Foo.getDefaultInstance())) { foo = any.unpack(Foo.getDefaultInstance()); } Example 3: Pack and unpack a message in Python. foo = Foo(...) any = Any() any.Pack(foo) ... if any.Is(Foo.DESCRIPTOR): any.Unpack(foo) ... Example 4: Pack and unpack a message in Go foo := &pb.Foo{...} any, err := anypb.New(foo) if err != nil { ... } ... foo := &pb.Foo{} if err := any.UnmarshalTo(foo); err != nil { ... } The pack methods provided by protobuf library will by default use 'type.googleapis.com/full.type.name' as the type URL and the unpack methods only use the fully qualified type name after the last '/' in the type URL, for example "foo.bar.com/x/y.z" will yield type name "y.z". JSON ==== The JSON representation of an `Any` value uses the regular representation of the deserialized, embedded message, with an additional field `@type` which contains the type URL. Example: package google.profile; message Person { string first_name = 1; string last_name = 2; } { "@type": "type.googleapis.com/google.profile.Person", "firstName": , "lastName": } If the embedded message type is well-known and has a custom JSON representation, that representation will be embedded adding a field `value` which holds the custom JSON in addition to the `@type` field. Example (for message [google.protobuf.Duration][]): { "@type": "type.googleapis.com/google.protobuf.Duration", "value": "1.212s" } - `@type` string — A URL/resource name that uniquely identifies the type of the serialized protocol buffer message. This string must contain at least one "/" character. The last segment of the URL's path must represent the fully qualified name of the type (as in `path/google.protobuf.Duration`). The name should be in a canonical form (e.g., leading "." is not accepted). In practice, teams usually precompile into the binary all types that they expect it to use in the context of Any. However, for URLs which use the scheme `http`, `https`, or no scheme, one can optionally set up a type server that maps type URLs to message definitions as follows: * If no scheme is provided, `https` is assumed. * An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format, or produce an error. * Applications are allowed to cache lookup results based on the URL, or have them precompiled into a binary to avoid any lookup. Therefore, binary compatibility needs to be preserved on changes to types. (Use versioned type names to manage breaking changes.) Note: this functionality is not currently available in the official protobuf release, and it is not used for type URLs beginning with type.googleapis.com. As of May 2023, there are no widely used type server implementations and no plans to implement one. Schemes other than `http`, `https` (or the empty scheme) might be used with implementation specific semantics. - `modeInfo` CosmosTxV1beta1ModeInfo — ModeInfo describes the signing mode of a single or nested multisig signer. - `single` CosmosTxV1beta1ModeInfoSingle - `mode` 'SIGN_MODE_UNSPECIFIED' | 'SIGN_MODE_DIRECT' | 'SIGN_MODE_TEXTUAL' | 'SIGN_MODE_DIRECT_AUX' | 'SIGN_MODE_LEGACY_AMINO_JSON' | 'SIGN_MODE_EIP_191' — SignMode represents a signing mode with its own security guarantees. This enum should be considered a registry of all known sign modes in the Cosmos ecosystem. Apps are not expected to support all known sign modes. Apps that would like to support custom sign modes are encouraged to open a small PR against this file to add a new case to this SignMode enum describing their sign mode so that different apps have a consistent version of this enum. - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be rejected. - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is verified with raw bytes from Tx. - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some human-readable textual representation on top of the binary representation from SIGN_MODE_DIRECT. Since: cosmos-sdk 0.50 - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses SignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not require signers signing over other signers' `signer_info`. Since: cosmos-sdk 0.46 - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses Amino JSON and will be removed in the future. - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos SDK. Ref: https://eips.ethereum.org/EIPS/eip-191 Currently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant, but is not implemented on the SDK by default. To enable EIP-191, you need to pass a custom `TxConfig` that has an implementation of `SignModeHandler` for EIP-191. The SDK may decide to fully support EIP-191 in the future. Since: cosmos-sdk 0.45.2 - `multi` CosmosTxV1beta1ModeInfoMulti - `bitarray` CosmosCryptoMultisigV1beta1CompactBitArray — CompactBitArray is an implementation of a space efficient bit array. This is used to ensure that the encoded data takes up a minimal amount of space after proto encoding. This is not thread safe, and is not intended for concurrent usage. - … - `modeInfos` CosmosTxV1beta1ModeInfo[] - `sequence` string, uint64 — sequence is the sequence of the account, which describes the number of committed transactions signed by a given address. It is used to prevent replay attacks. - `fee` CosmosTxV1beta1Fee — Fee includes the amount of coins paid in fees and the maximum gas to be used by the transaction. The ratio yields an effective "gasprice", which must be above some minimum to be accepted into the mempool. - `amount` CosmosBaseV1beta1Coin[] - `denom` string - `amount` string - `gasLimit` string, uint64 - `payer` string — if unset, the first signer is responsible for paying the fees. If set, the specified account must pay the fees. the payer must be a tx signer (and thus have signed this field in AuthInfo). setting this field does *not* change the ordering of required signers for the transaction. - `granter` string - `tip` CosmosTxV1beta1Tip — Tip is the tip used for meta-transactions. - `amount` CosmosBaseV1beta1Coin[] - `denom` string - `amount` string - `tipper` string - `signatures` string[] — signatures is a list of signatures that matches the length and order of AuthInfo's signer_infos to allow connecting signature meta information like public key and signing mode by position. - `blockId` TendermintTypesBlockID - `hash` string, byte - `partSetHeader` TendermintTypesPartSetHeader - `total` integer - `hash` string, byte - `block` TendermintTypesBlock - `header` TendermintTypesHeader — Header defines the structure of a block header. - `version` TendermintVersionConsensus — Consensus captures the consensus rules for processing a block in the blockchain, including all blockchain data structures and the rules of the application's state transition machine. - `block` string, uint64 - `app` string, uint64 - `chainId` string - `height` string, int64 - `time` string, date-time - `lastBlockId` TendermintTypesBlockID - `hash` string, byte - `partSetHeader` TendermintTypesPartSetHeader - `total` integer - `hash` string, byte - `lastCommitHash` string, byte — commit from validators from the last block - `dataHash` string, byte - `validatorsHash` string, byte — validators for the current block - `nextValidatorsHash` string, byte - `consensusHash` string, byte - `appHash` string, byte - `lastResultsHash` string, byte - `evidenceHash` string, byte — evidence included in the block - `proposerAddress` string, byte - `data` TendermintTypesData - `txs` string[] — Txs that will be applied by state @ block.Height+1. NOTE: not all txs here are valid. We're just agreeing on the order first. This means that block.AppHash does not include these txs. - `evidence` TendermintTypesEvidenceList - `evidence` TendermintTypesEvidence[] - `duplicateVoteEvidence` TendermintTypesDuplicateVoteEvidence — DuplicateVoteEvidence contains evidence of a validator signed two conflicting votes. - `voteA` TendermintTypesVote — Vote represents a prevote or precommit vote from validators for consensus. - `type` 'SIGNED_MSG_TYPE_UNKNOWN' | 'SIGNED_MSG_TYPE_PREVOTE' | 'SIGNED_MSG_TYPE_PRECOMMIT' | 'SIGNED_MSG_TYPE_PROPOSAL' — SignedMsgType is a type of signed message in the consensus. - SIGNED_MSG_TYPE_PREVOTE: Votes - SIGNED_MSG_TYPE_PROPOSAL: Proposals - `height` string, int64 - `round` integer - `blockId` TendermintTypesBlockID - … - `timestamp` string, date-time - `validatorAddress` string, byte - `validatorIndex` integer - `signature` string, byte — Vote signature by the validator if they participated in consensus for the associated block. - `extension` string, byte — Vote extension provided by the application. Only valid for precommit messages. - `extensionSignature` string, byte — Vote extension signature by the validator if they participated in consensus for the associated block. Only valid for precommit messages. - `voteB` TendermintTypesVote — Vote represents a prevote or precommit vote from validators for consensus. - `type` 'SIGNED_MSG_TYPE_UNKNOWN' | 'SIGNED_MSG_TYPE_PREVOTE' | 'SIGNED_MSG_TYPE_PRECOMMIT' | 'SIGNED_MSG_TYPE_PROPOSAL' — SignedMsgType is a type of signed message in the consensus. - SIGNED_MSG_TYPE_PREVOTE: Votes - SIGNED_MSG_TYPE_PROPOSAL: Proposals - `height` string, int64 - `round` integer - `blockId` TendermintTypesBlockID - … - `timestamp` string, date-time - `validatorAddress` string, byte - `validatorIndex` integer - `signature` string, byte — Vote signature by the validator if they participated in consensus for the associated block. - `extension` string, byte — Vote extension provided by the application. Only valid for precommit messages. - `extensionSignature` string, byte — Vote extension signature by the validator if they participated in consensus for the associated block. Only valid for precommit messages. - `totalVotingPower` string, int64 - `validatorPower` string, int64 - `timestamp` string, date-time - `lightClientAttackEvidence` TendermintTypesLightClientAttackEvidence — LightClientAttackEvidence contains evidence of a set of validators attempting to mislead a light client. - `conflictingBlock` TendermintTypesLightBlock - `signedHeader` TendermintTypesSignedHeader - … - `validatorSet` TendermintTypesValidatorSet - … - `commonHeight` string, int64 - `byzantineValidators` TendermintTypesValidator[] - `address` string, byte - `pubKey` TendermintCryptoPublicKey - … - `votingPower` string, int64 - `proposerPriority` string, int64 - `totalVotingPower` string, int64 - `timestamp` string, date-time - `lastCommit` TendermintTypesCommit — Commit contains the evidence that a block was committed by a set of validators. - `height` string, int64 - `round` integer - `blockId` TendermintTypesBlockID - `hash` string, byte - `partSetHeader` TendermintTypesPartSetHeader - `total` integer - `hash` string, byte - `signatures` TendermintTypesCommitSig[] - `blockIdFlag` 'BLOCK_ID_FLAG_UNKNOWN' | 'BLOCK_ID_FLAG_ABSENT' | 'BLOCK_ID_FLAG_COMMIT' | 'BLOCK_ID_FLAG_NIL' — - BLOCK_ID_FLAG_UNKNOWN: indicates an error condition - BLOCK_ID_FLAG_ABSENT: the vote was not received - BLOCK_ID_FLAG_COMMIT: voted for the block that received the majority - BLOCK_ID_FLAG_NIL: voted for nil - `validatorAddress` string, byte - `timestamp` string, date-time - `signature` string, byte - `pagination` CosmosBaseQueryV1beta1PageResponse — PageResponse is to be embedded in gRPC response messages where the corresponding request message has used PageRequest. message SomeResponse { repeated Bar results = 1; PageResponse page = 2; } - `nextKey` string, byte — next_key is the key to be passed to PageRequest.key to query the next page most efficiently. It will be empty if there are no more results. - `total` string, uint64 ## Other responses - `default` — An unexpected error response. --- [API](https://skmtc.net/haqq-network/apis/haqq-network-grpc-api.md) · [All operations](https://skmtc.net/haqq-network/apis/haqq-network-grpc-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/haqq-network/haqq-network-grpc-api/versions/2d0419923f40/schema)