# transaction

**Type:** GraphQL queries

**Description:**
Retrieve a specific transaction by its request key, with optional additional filters.

While a `requestKey` uniquely identifies a transaction at the Pact level, the same request key
can appear in **multiple blocks** due to chain reorganization or orphaned blocks. Because of this,
retrieving a transaction by `requestKey` alone may return more than one match over the chain’s history.

To disambiguate results, you can provide the `blockHash` parameter.
- A specific `requestKey` combined with a `blockHash` will always return **at most one transaction**, since that pair is unique.
- Among those combinations, **only one transaction will belong to a canonical block** (i.e., part of the main chain).
- All other matches (with the same `requestKey` but different `blockHash` values) represent transactions included in **orphaned blocks** — blocks that were mined but later discarded due to chain reorganization.

The `minimumDepth` parameter can also be used to limit results to transactions in blocks that are at least a certain depth from the chain tip, helping ensure finality.

This query is typically used when you need to verify the canonical inclusion of a transaction or inspect all occurrences of a given request key across the chain’s history.

## Arguments
- blockHash (String): The hash of the block that contains the transaction.
When provided along with `requestKey`, guarantees a unique match.
Only one such combination will correspond to a canonical block; others (if any) are from orphaned blocks.
- minimumDepth (Int): The minimum depth (distance from the chain tip) the block containing the transaction must have.
Useful to filter for transactions in finalized blocks.
- requestKey (String): The unique request key of the transaction.
Note: The same request key can appear in multiple blocks over time due to chain reorganizations.

## Response
**Type:** Transaction
**Description:**
Represents a transaction executed on the Kadena blockchain.

A `Transaction` encapsulates the full structure and outcome of a blockchain transaction —
from the original signed command to the resulting execution details.
Each transaction is uniquely identified by its `hash` and includes the submitted command (`cmd`),
associated signatures (`sigs`), and the execution result (`result`).

This type is fundamental for querying and analyzing blockchain activity, tracking execution outcomes,
and verifying signed payloads.

### Fields
- id (ID): Globally unique identifier for this transaction node.
- cmd (TransactionCommand): The original signed transaction command submitted to the network.
Includes metadata, payload, signers, and network information.
- hash (String): The unique hash of the transaction.
This value is derived from the signed command and serves as the canonical identifier
for the transaction on-chain.
- result (TransactionInfo): The result of executing the transaction.
Includes information such as success/failure status, events, continuation data,
and any state changes triggered by execution.
- sigs (TransactionSignature): The list of signatures associated with the transaction.
Each signature proves authorization from a required signer and is used to validate
that the transaction was properly authorized before execution.