confirmTransaction

Overview

The confirmTransaction JSON-RPC method, historically present in earlier iterations of the Solana RPC API, was designed to provide clients with a straightforward mechanism to ascertain the confirmation status of a submitted transaction. Upon invocation, clients would typically supply a transaction signature, and the RPC node would poll its internal state until the transaction reached a specified commitment level (e.g., finalized, confirmed). The method would then return a simple boolean value indicating whether the transaction was successfully confirmed according to the requested commitment.

While conceptually simple, confirmTransaction faced limitations as the Solana network evolved. Its polling-based nature could be inefficient for clients needing granular status updates or when dealing with high transaction volumes. More critically, the method offered minimal insight beyond a binary confirmation status, lacking details such as error messages, block data, or the specific slot in which the transaction was processed.

It is crucial to note that the confirmTransaction method is deprecated and is no longer part of the official Solana JSON-RPC API specification. Modern Solana applications and SDKs have transitioned to more robust and informative methods for transaction confirmation. The recommended approaches now include using getSignatureStatuses for polling signature status, getTransaction with appropriate commitment levels for detailed transaction data and confirmation, or leveraging the signatureSubscribe WebSocket method for real-time, push-based updates on transaction finality.

Parameters

As confirmTransaction is deprecated, the following parameters describe what it conceptually accepted or historically did in older RPC versions.

NameTypeRequired/OptionalDescription
signaturestringRequiredThe Base58-encoded transaction signature to confirm. This unique identifier is returned by the RPC method that broadcasts the transaction (e.g., sendTransaction). The RPC node would use this signature to query the status of the transaction within the ledger.
commitmentstringOptionalSpecifies the commitment level required for confirmation. The method would wait until the transaction reached at least this level. Historical options included processed, confirmed, and finalized. If omitted, the default commitment configured on the RPC node (often finalized) would be used.

Expected Response

Given the deprecated nature of confirmTransaction, its historical or conceptual response was straightforward, typically indicating a binary success or failure to achieve the requested confirmation.

The JSON-RPC response object would generally conform to the standard structure:

1{
2  "jsonrpc": "2.0",
3  "result": boolean_value,
4  "id": integer_value
5}

The key properties in the response object would be:

  • jsonrpc: A string indicating the JSON-RPC protocol version, always "2.0".
  • result: A boolean value.
    • true if the transaction was successfully confirmed at the specified commitment level within the RPC node's configured timeout.
    • false if the transaction could not be confirmed within the timeout, or if it failed to reach the specified commitment level (e.g., due to an error, being dropped, or never being included in a block that reached the required commitment).
  • id: An integer representing the request ID, matching the id provided in the original request.

In summary, the result field was the primary payload, providing a simple answer to whether a given transaction signature had achieved the desired state of finality on the network from the perspective of the polled RPC node. Modern alternatives like getTransaction provide a much richer meta field for detailed transaction outcomes.

Usage Examples

TypeScript (Fetch)

1const response = await fetch("http://[IP_ADDRESS]:[PORT]", {
2  method: "POST",
3  headers: {
4    "Content-Type": "application/json",
5  },
6  body: JSON.stringify({
7    jsonrpc: "2.0",
8    id: 1,
9    method: "confirmTransaction",
10    params: [] // Add relevant parameters here
11  }),
12});
13
14const data = await response.json();
15console.log(data);

Python (Requests)

1import requests
2import json
3
4url = "http://[IP_ADDRESS]:[PORT]"
5payload = json.dumps({
6  "jsonrpc": "2.0",
7  "id": 1,
8  "method": "confirmTransaction",
9  "params": [] # Add relevant parameters here
10})
11headers = {
12  'Content-Type': 'application/json'
13}
14
15response = requests.request("POST", url, headers=headers, data=payload)
16print(response.text)

Rust (reqwest)

1use reqwest::Client;
2use serde_json::json;
3
4#[tokio::main]
5async fn main() -> Result<(), Box<dyn std::error::Error>> {
6    let client = Client::new();
7    let res = client.post("http://[IP_ADDRESS]:[PORT]")
8        .json(&json!({
9            "jsonrpc": "2.0",
10            "id": 1,
11            "method": "confirmTransaction",
12            "params": [] // Add relevant parameters here
13        }))
14        .send()
15        .await?
16        .text()
17        .await?;
18
19    println!("{}", res);
20    Ok(())
21}