get
Returns full details for a single confirmed transaction by signature.
getTransaction looks up one transaction by signature and returns everything recorded about it: the compiled message, account keys, before/after balances, log messages, compute units consumed, and any error.
Mainnet carries three transaction formats — legacy, version 0 (Address Lookup Tables) and version 1 — decoded together by maxSupportedTransactionVersion: 1; omitting it fails on anything newer than legacy. See Transaction v1.
Parameters
params is a JSON array, with values in this order: signature, config.
Transaction signature to look up, as a base-58 encoded string.
Optional configuration.
Show propertiesProperties
Bank state to read the transaction from. processed is not accepted here.
confirmedfinalizedEncoding for the transaction field. jsonParsed decodes known program instructions into structured objects; unrecognized programs fall back to raw account/data form even when jsonParsed is requested.
jsonjsonParsedbase58base64Highest transaction version the caller can decode, as a ceiling rather than a filter: 1 returns legacy, version 0 and version 1 transactions alike. The value must be the JSON integer 1, not the string "1" (-32602); omitting it returns legacy only and fails with -32015 on a versioned signature. Raising it before the client can decode the format just moves the failure elsewhere.
0Maximum: 11Result
The transaction record, or null if the signature isn't known to this node at the requested commitment.
Show one ofOne of
Show propertiesProperties
Slot this transaction was processed in.
Estimated production time of the containing block, as Unix seconds.
Index of this transaction within its block.
"legacy", or the integer version number 0 or 1.
Show propertiesProperties
All signatures on the transaction, fee payer's first.
Show propertiesProperties
Every account the transaction reads or writes, including ones resolved via address lookup tables.
Address Lookup Table references used to extend the account list. Version 0 only: legacy and version 1 transactions cannot use lookup tables, so the field is absent.
Top-level instructions, in execution order.
Present on version 1 transactions only: the fee and resource requests encoded in the message itself, in place of ComputeBudget instructions. Every field is present; null means the sender left it unset. See Transaction v1.
Show propertiesProperties
Priority fee for the whole transaction, as a total in lamports — not micro-lamports per compute unit, and not a price. null means no priority fee was requested (treated as 0).
Requested compute unit limit, in compute units. null means unset, which is treated as 0 — not as the legacy per-instruction default.
Requested cap on loaded account data, in bytes. null means unset, which is treated as 0 — not as the 64 MiB default a legacy or version 0 transaction gets.
Requested heap size, in bytes: a multiple of 1 KiB between 32 KiB and 256 KiB. null means unset, which is the 32 KiB minimum.
Show propertiesProperties
Null on success; a TransactionError variant object on failure.
Total fee charged, in lamports.
Compute units actually consumed while executing the transaction.
What this transaction charged against the block's cost limits, usually larger than computeUnitsConsumed since the cost model adds signatures, write locks, size and loaded account data on top of execution. It measures block space, while computeUnitsConsumed measures the compute budget; absent when the node recorded no cost figure.
Lamport balance of every account in accountKeys, before the transaction.
Lamport balance of every account in accountKeys, after the transaction.
Token balances for any SPL token accounts referenced, before the transaction.
Token balances for any SPL token accounts referenced, after the transaction.
Program log output, in emission order.
Instructions invoked via cross-program invocation (CPI), grouped by the top-level instruction index that triggered them.
Any rewards paid out as a side effect of this transaction (rare outside vote/stake-related transactions).
Writable/readonly account addresses resolved via address lookup tables. Version 0 only: legacy and version 1 transactions carry their whole account list in the message.
Notes
- The example is trimmed: the real transaction has 63 account keys (mostly resolved via 6 address lookup tables), 5 top-level instructions and 10 pre/post token balance entries, reflected by
truncated: true. maxSupportedTransactionVersion: 1, unless there is a specific reason to omit it, covers both version 0 and version 1 transactions, a large share of mainnet traffic; without it, this call fails on either.- The example is a version 0 transaction fetched with a ceiling of
1. A version 1 transaction instead carries atransactionConfigobject intransaction.messagewith no address lookup tables, so code that scans instructions forComputeBudget111111111111111111111111111111to read a priority fee silently reports zero. See Transaction v1. encoding: "base58"works withmaxSupportedTransactionVersion: 1, the same as the other encodings.- constant-k keeps a rolling window of ledger history, not a full archive; a signature older than the retention window returns
nulleven though it is valid.minimumLedgerSlotorgetFirstAvailableBlock, compared against the transaction's slot, confirms whether it is in range.