Migrating Off Deprecated Solana RPC Methods: getConfirmedBlock and Legacy getConfirmed API Calls

Direct Answer: Replace getConfirmed* with Canonical Methods and Explicit Commitment

If your Solana client code calls getConfirmedBlock, getConfirmedSignaturesForAddress2, getConfirmedTransaction, or getConfirmedSlot, you must migrate to the canonical method family—getBlock, getSignaturesForAddress, getTransaction, and getSlot—and pass an explicit commitment (usually 'confirmed') to preserve the original data semantics. The legacy methods are being removed from current Solana (Agave) releases, and after removal they return a JSON-RPC -32601 "Method not found" error. The migration is not just a rename: you must also handle response-shape differences (e.g., maxSupportedTransactionVersion for versioned transactions) and verify that your RPC provider still exposes the legacy methods, as some relays disable them.

This guide is grounded in the official Solana RPC documentation and the deprecation/removal list current as of the published reference. Removal status varies by chain-software release and provider, so always verify against your target endpoint and the Solana JSON-RPC methods reference rather than assuming a fixed global date.

• Legacy methods were equivalent to the current family but baked in 'confirmed' commitment semantics.
• Newer releases collapse these into a single family that takes a commitment argument.
• Old callers hit 'Method not found' once the method is removed.
• Migration requires mapping each method and adding explicit commitment.
• Always test against your provider; some may disable legacy methods even before chain-software removal.

Why the getConfirmed* Methods Are Being Removed

Historically, Solana offered parallel 'confirmed' variants—getConfirmedBlock, getConfirmedSignaturesForAddress2, getConfirmedTransaction, getConfirmedSlot—that were equivalent to the current getBlock, getSignaturesForAddress, getTransaction, and getSlot but were baked around older block-commitment semantics. Before the finalized/confirmed/processed commitment model and the unified blockstore API, these methods provided a way to query data that had reached a specific confirmation level.

As the protocol evolved, the commitment model was unified: every relevant method now accepts a commitment parameter (or uses a default) to specify whether you want processed, confirmed, or finalized data. The redundant suffixed methods became unnecessary and were deprecated. Current Agave releases are removing them, as documented in the official Solana RPC 'Removed RPC Methods' list. The removal is part of a broader cleanup tracked in GitHub Issue #2859 (independent source).

For integrators, the practical impact is that code written against the old getConfirmed* batch will break with a -32601 error once the method is removed. The fix is to switch to the canonical methods and explicitly pass commitment: 'confirmed' (or the appropriate level) to maintain the same data semantics.

• Old methods were equivalent to current ones but with hardcoded 'confirmed' commitment.
• Unified commitment model made redundant methods unnecessary.
• Removal is happening in current Agave releases; verify against your target.
• After removal, calls return 'Method not found' JSON-RPC error.

Exact Method Mapping and Semantics Preservation

The table below shows the exact mapping you must apply. The key is to preserve the original 'confirmed' semantics by passing commitment: 'confirmed' where the method accepts it. For getBlock, the default commitment is 'confirmed', but it's safer to be explicit.

For transaction confirmation logic (e.g., 'did my confirmed tx land?'), use getSignatureStatuses with searchTransactionHistory or getTransaction with a commitment. The nuance: processed means the transaction was accepted by the leader, confirmed means the block was voted on, and finalized means the block is irreversible. Choose the commitment that matches your business threshold—for most applications, confirmed is sufficient, but for irreversible work (e.g., financial settlements) use finalized.

• Always pass commitment: 'confirmed' to preserve original semantics.
• For getBlock, you may need maxSupportedTransactionVersion to avoid errors with versioned transactions.
• Use getSignatureStatuses or getTransaction for confirmation status checks.
• Understand the difference between processed, confirmed, and finalized to pick the right commitment.

Practical Migration Risks and How to Handle Them

Response-shape differences are the most common pitfall. Older getConfirmedBlock may return block data in a different encoding than modern getBlock. For example, modern getBlock requires maxSupportedTransactionVersion to be set if the block contains versioned transactions; otherwise it returns an error. Also, the transactionDetails and rewards parameters affect the response structure. Always parse the response defensively.

Provider-level differences: some RPC providers may disable legacy methods even before chain-software removal. This is a relay configuration choice. Always check your provider's documentation or test with a probe. OnFinality's API service and Solana RPC endpoints may have specific policies; verify with your endpoint.

Graceful feature detection: implement a probe that calls the legacy method and catches the -32601 error. If it fails, route to the canonical method. This ensures your code works both before and after removal.

• Response shapes differ: handle maxSupportedTransactionVersion and transactionDetails.
• Providers may disable legacy methods; test with a probe.
• Implement feature detection to gracefully fall back.
• Use defensive parsing to avoid crashes on unexpected fields.

Reproducible Migration Checklist and Code Example

Use the following checklist to migrate your codebase. Then run the Node.js example below against your endpoint to verify the behavior.

Migration Checklist

1. Identify all calls to getConfirmedBlock, getConfirmedSignaturesForAddress2, getConfirmedTransaction, getConfirmedSlot, and legacy getSignaturesForAddress.
2. Replace each with the canonical method from the mapping table.
3. Add commitment: 'confirmed' (or your desired level) to each call.
4. For getBlock, add maxSupportedTransactionVersion: 0 (or the highest version you support) to avoid versioned-transaction errors.
5. Update response parsing to handle new fields (e.g., blockHeight, blockTime may be null).
6. Test against a devnet or testnet endpoint that still supports legacy methods to compare responses.
7. Implement feature detection to fall back to canonical methods if legacy methods are unavailable.
8. Deploy and monitor for -32601 errors.

• Expected output: 'Legacy method error: Method not found' (if removed), then confirmed slot, block height, signatures count, and transaction status.
• Fill in the results table below with your endpoint's behavior.

// Node.js example using @solana/web3.js
const { Connection, clusterApiUrl } = require('@solana/web3.js');

// Replace with your endpoint
const endpoint = process.env.RPC_URL || clusterApiUrl('devnet');
const connection = new Connection(endpoint, 'confirmed');

async function probeLegacyMethod() {
  try {
    // Probe with a known slot (e.g., 0) - this will likely fail on modern nodes
    await connection.getConfirmedBlock(0);
    console.log('Legacy method available');
  } catch (err) {
    console.log('Legacy method error:', err.message);
  }
}

async function canonicalCalls() {
  // Get latest confirmed slot
  const slot = await connection.getSlot('confirmed');
  console.log('Confirmed slot:', slot);

  // Get block with maxSupportedTransactionVersion
  const block = await connection.getBlock(slot, {
    commitment: 'confirmed',
    maxSupportedTransactionVersion: 0
  });
  console.log('Block height:', block.blockHeight);

  // Get signatures for an address (example address)
  const address = 'Vote111111111111111111111111111111111111111';
  const signatures = await connection.getSignaturesForAddress(address, {
    limit: 1,
    commitment: 'confirmed'
  });
  console.log('Signatures count:', signatures.length);

  // Get transaction status for a signature (if any)
  if (signatures.length > 0) {
    const sig = signatures[0].signature;
    const status = await connection.getSignatureStatus(sig, { searchTransactionHistory: true });
    console.log('Transaction status:', status.value?.confirmationStatus);
  }
}

probeLegacyMethod().then(canonicalCalls).catch(console.error);

Results Table for Your Environment

Record the results of the probe and canonical calls against your endpoint. This helps you document the behavior for your team and verify the migration.

Failure/Fix Checklist for Common Errors

When migrating, you may encounter specific errors. Use this checklist to diagnose and fix them.

• Error -32601 Method not found: The legacy method is removed or disabled. Switch to the canonical method.
• Error -32602 Invalid params: You may be missing required parameters like maxSupportedTransactionVersion for getBlock. Add it.
• Error -32007 Slot skipped: The slot you requested is not available (e.g., due to skipping). Use a different slot or handle the error gracefully.
• Error -32004 Block not available: The block is not yet confirmed. Wait and retry, or use a lower commitment.
• Versioned transaction parse errors: Ensure you set maxSupportedTransactionVersion to a value that includes the version of the transactions in the block.

• Always check the exact error code and message.
• Refer to the Solana RPC timeouts and retries guide for handling transient errors.
• If you hit rate limits, see Solana rate limits and 429s.

Limitations and Tradeoffs of the Migration

The migration is straightforward but has tradeoffs. The canonical methods are more flexible, but they require you to be explicit about commitment, which can lead to subtle bugs if you forget to pass it. Also, the response shapes are not identical; you may need to update your data parsing logic. For example, getBlock returns a blockHeight field that may be null for older blocks, and getTransaction returns a meta object that can be null if the transaction was pruned.

Another limitation is that not all providers support the same set of methods. Some may still expose legacy methods for backward compatibility, but this is not guaranteed. Always test in your environment. The official Solana documentation and the Solana JSON-RPC methods reference are the authoritative sources for method availability.

Finally, the removal timeline is not fixed; it depends on the chain-software release you target. As of the date of this article (2026-09-06), the deprecation list is current, but you should verify against your node's version and provider documentation.

• Canonical methods require explicit commitment; forgetting it defaults to 'finalized' for some methods, which may not match your needs.
• Response shapes differ; update parsing logic.
• Provider support varies; test with a probe.
• Removal timeline varies by release; verify with your provider.

Next Steps and Further Reading

After migrating, ensure your code is robust by reviewing related best practices. For a deeper understanding of Solana's data model, see Solana versioned transactions and getBlock parsing. If you're querying historical data, the Querying Solana historical data over RPC guide is essential.

For operational concerns, review Solana RPC timeouts and retries and Solana rate limits and 429s. If you're new to Solana RPC, start with the Solana JSON-RPC methods (RPC Assistant) and the OnFinality Learn hub. For endpoint selection and pricing, see RPC pricing and the API service.

Finally, always refer to the official Solana RPC documentation for the most up-to-date method list and deprecation status.

• Review the official Solana RPC docs for the latest deprecation list.
• Use the RPC Assistant to explore method parameters and examples.
• Test your migration on devnet before deploying to mainnet.