Skip to main content

getSignatureStatuses

Returns the statuses of a list of signatures. Each signature must be a txid, the first signature of a transaction.

Common use cases
Poll Transaction Confirmation StatusCheck multiple transaction signatures simultaneously (up to 256) to determine their confirmation status at a specific commitment level. Essential for wallet applications and transaction monitoring systems that need to track transaction progress from processed to finalized states.
Implement Transaction Confirmation TimeoutCombine with polling intervals (typically 250ms-3s) and timeouts (15s-90s) to detect when transactions fail to confirm within expected timeframes. Use lastValidBlockHeight to identify expired transactions that will never confirm.
Search Historical Transaction StatusEnable searchTransactionHistory parameter to query transaction status beyond the recent status cache, searching local block storage and archival systems. Critical for retrieving status of older transactions that have aged out of the active slots cache.
Recover from WebSocket DisconnectionsUse as fallback when signatureSubscribe WebSocket connections are lost or notifications are missed. Directly fetch confirmation status to recover transaction monitoring state and avoid waiting indefinitely for notifications that never arrive.
Batch Status VerificationEfficiently check status for multiple pending transactions in a single RPC call rather than making individual requests. Reduces RPC load and network overhead when monitoring many concurrent transactions in high-throughput applications.

Parameters​

pubkey (array, required)

An array of transaction signatures to confirm, as base-58 encoded strings (up to a maximum of 256)

config (object, optional)

Configuration object containing the following fields:

Fields:

  • searchTransactionHistory (bool): if true - a Solana node will search its ledger cache for any signatures not found in the recent status cache

Request​

curl https://solana-mainnet.api.syndica.io/api-key/YOUR_API_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getSignatureStatuses",
  "params": [
    [
      "5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
    ],
    {
      "searchTransactionHistory": true
    }
  ]
}'
Network Selection

Replace mainnet with devnet in the URL to query devnet instead.

Response​

{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 82
    },
    "value": [
      {
        "slot": 48,
        "confirmations": null,
        "err": null,
        "status": {
          "Ok": null
        },
        "confirmationStatus": "finalized"
      },
      null
    ]
  },
  "id": 1
}

Response Fields​

Return value: array

An array of RpcResponse<object> consisting of either null or an object containing the following fields:

FAQ and Troubleshooting​

Why does getSignatureStatuses return null for my transaction?

The method returns null when: 1) The transaction signature doesn't exist in the status cache (limited to active slots + MAX_RECENT_BLOCKHASHES rooted slots), 2) searchTransactionHistory is false (default) and the transaction is older than the cache window, or 3) The transaction was never successfully submitted to the network. Set searchTransactionHistory: true to search beyond the cache.

What is the difference between confirmations and confirmationStatus fields?

confirmationStatus is a string ('processed', 'confirmed', 'finalized') indicating the commitment level achieved, while confirmations is a numeric count of blocks since confirmation. The confirmations field returns null for finalized transactions (as they are immutable) or contains the block depth for confirmed/processed states.

How long should I poll getSignatureStatuses before timing out?

Common patterns use 60-90 second timeouts with 250ms-3s polling intervals. Transactions typically confirm in seconds, but network congestion can delay processing. After a timeout, check if the transaction's lastValidBlockHeight has passed - expired transactions will never confirm and should be considered failed.

Should I use searchTransactionHistory for all queries?

No - only use searchTransactionHistory: true when necessary, as it increases RPC node load by searching block storage and archives. For recent transactions (within ~150 slots), the default cache-only search is sufficient and more performant. Use the history search for older transactions or when recovering lost state.

Can I check transaction status across different commitment levels simultaneously?

getSignatureStatuses returns the current highest commitment level achieved by each transaction. To monitor different commitment thresholds, call the method with the desired commitment parameter or compare the returned confirmationStatus field against your target level (processed < confirmed < finalized).

signatureSubscribe
WebSocket subscription for real-time signature confirmation notifications. Use as primary monitoring method with getSignatureStatuses as fallback for missed notifications or connection recovery.

getTransaction
Fetch complete transaction details including logs, accounts, and metadata after confirmation. Use getSignatureStatuses first to verify transaction reached desired commitment level before retrieving full transaction data.

getSignaturesForAddress
Query all transaction signatures for a specific address with pagination support. Returns signature list that can be batch-checked with getSignatureStatuses to verify confirmation status of address activity.

sendTransaction
Submit signed transactions to the network. After sending, use getSignatureStatuses to poll for confirmation status until the transaction reaches the target commitment level or times out.

getLatestBlockhash
Retrieve recent blockhash and lastValidBlockHeight for transaction construction. Compare lastValidBlockHeight with current slot during status polling to detect expired transactions that will never confirm.

External Resources​