Solana getVersion and Runtime Features: Probing Node Capabilities

The Role of getVersion in Solana RPC

The getVersion RPC method is a lightweight call that returns the software version of the Solana node you are connected to, along with a feature-set map. According to the Solana getVersion documentation, the response includes a solana-core version string and a feature-set object where each key is a feature-gate identifier (a base58-encoded public key) and each value is the activation slot for that feature. This information is crucial for clients that need to ensure compatibility before invoking newer RPC methods or interpreting transaction formats that depend on specific runtime features.

Unlike methods that query blockchain state, getVersion reports the node's own software configuration. It does not require any parameters and is typically fast to respond. Because it reflects the node's advertised capabilities, it is the first step in building a capability profile for an RPC endpoint. You can use it alongside other health and cluster methods to form a complete picture, as described in the Solana API guide (RPC Assistant).

• Returns solana-core version string (e.g., '1.18.22').
• Returns feature-set map: feature ID → activation slot.
• No parameters required; safe to call frequently.
• Advertised feature-set may lag behind cluster if node is not fully synced.

Understanding Solana Feature Gates and Activation

Solana feature gates are runtime changes that are activated at a specific slot once a supermajority of stake has voted to enable them. Each feature is identified by a unique public key, and its activation slot is recorded on-chain. The Solana feature gates reference explains that features can change transaction processing, add new RPC methods, or alter the behavior of existing ones. When a feature is activated, nodes that have upgraded to a software version supporting that feature will begin enforcing the new behavior from the activation slot onward.

Because feature activation is coordinated across the cluster, nodes running older software may not recognize a feature and could reject transactions or return errors for methods that depend on it. Therefore, checking the feature-set from getVersion helps you determine whether a node is aware of a feature before you rely on it. However, the presence of a feature in the feature-set does not guarantee that the node has fully activated it; the activation slot indicates when it should become active, but the node must also be healthy and near the chain tip to process transactions correctly.

• Feature gates are identified by public keys and activated at specific slots.
• Activation requires stake-weighted vote and software support.
• Nodes on older versions may not include newer features in their feature-set.
• Feature-set presence is necessary but not sufficient for method availability.

Building a Node-Capability Record with getVersion, getHealth, getClusterNodes, and getEpochInfo

A single getVersion call gives you the advertised version and feature-set, but to trust that information you need to confirm the node is healthy and synchronized. The getHealth method returns 'ok' if the node is within a certain threshold of the cluster, while getEpochInfo provides the current epoch, slot, and transaction count. getClusterNodes lists all nodes in the cluster with their versions, which helps you compare your endpoint's version against the cluster majority.

By combining these calls, you can build a capability record that includes: the node's solana-core version, its feature-set, its health status, the current epoch and slot, and the cluster's version distribution. This record should be cached per endpoint and refreshed periodically, because nodes can be upgraded or fall behind. For a deeper discussion on detecting lag, see Detecting an RPC node behind the chain tip.

• getVersion: version and feature-set.
• getHealth: returns 'ok' if node is healthy.
• getEpochInfo: current epoch, slot, and transaction count.
• getClusterNodes: list of cluster nodes with versions.
• Cache the combined record per endpoint and refresh regularly.

Detecting a Node That Lags a Rollout

When a new feature is rolled out, nodes that have not upgraded will not advertise it in their feature-set. If you attempt to use a method that depends on that feature, the node may return a 'method not found' error or reject a transaction with an unsupported version. To detect such lag, compare the node's solana-core version with the majority version reported by getClusterNodes. If your endpoint is significantly behind, it may not support newer transaction formats or RPC methods.

Additionally, check the activation slot of the feature you need. If the current slot from getEpochInfo is past the activation slot but the feature is missing from the node's feature-set, the node is likely running outdated software. In that case, you should switch to a different endpoint or wait for the node to upgrade. Monitoring tools can automate this check; see Monitoring RPC endpoints for strategies.

• Compare node version with cluster majority from getClusterNodes.
• Check if current slot > feature activation slot but feature missing.
• Lagging nodes may reject newer transaction formats.
• Switch endpoints or wait for upgrade if lag detected.

Runnable Node.js Example: Probing getVersion and Feature-Set

The following Node.js script connects to a Solana RPC endpoint, calls getVersion, extracts the feature-set keys, and checks for a specific feature ID. It also prints the advertised version. You can adapt this to your own feature of interest by replacing the FEATURE_ID constant. This example uses the @solana/web3.js library, but you can also use raw HTTP requests.

Before running, ensure you have Node.js installed and the @solana/web3.js package. The script uses a public RPC endpoint for demonstration; replace it with your own endpoint URL. The output will show the version and whether the feature is present.

const { Connection } = require('@solana/web3.js');

// Replace with your RPC endpoint
const RPC_URL = 'https://api.mainnet-beta.solana.com';
const FEATURE_ID = '3a8f5b7c9d2e1f0a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a'; // example feature ID

async function probeNode() {
  const connection = new Connection(RPC_URL, 'confirmed');
  try {
    const versionInfo = await connection.getVersion();
    console.log('solana-core version:', versionInfo['solana-core']);
    const featureSet = versionInfo['feature-set'];
    const featureKeys = Object.keys(featureSet);
    console.log('Number of features advertised:', featureKeys.length);
    if (featureKeys.includes(FEATURE_ID)) {
      console.log(`Feature ${FEATURE_ID} is present, activation slot: ${featureSet[FEATURE_ID]}`);
    } else {
      console.log(`Feature ${FEATURE_ID} is NOT present in the advertised feature-set.`);
    }
  } catch (err) {
    console.error('Error probing node:', err);
  }
}

probeNode();

Verifying Capability Claims with getHealth and getSlot

A feature-set entry alone does not guarantee that the node will successfully process a transaction that uses that feature. The node must also be healthy and near the chain tip. After calling getVersion, call getHealth to ensure the node returns 'ok', and getSlot to check the current slot. If the node is behind, it may not have processed the latest blocks and could fail to simulate or send transactions correctly.

For example, if you are about to send a versioned transaction that relies on a recently activated feature, you should verify that the node's slot is within a few slots of the cluster's highest slot. You can get the cluster's highest slot from getClusterNodes or by querying multiple endpoints. Only trust the capability claim when the node is healthy and its slot is close to the tip. This practice is part of a robust Solana commitment levels and confirmation strategy.

• Call getHealth after getVersion; expect 'ok'.
• Call getSlot and compare with cluster's highest slot.
• If node is behind, capability claim is unreliable.
• Combine health and slot checks before sending transactions.

Results Table: Measuring Your Endpoint's Capability Profile

To systematically assess an RPC endpoint, create a results table that records the outputs of the capability probes. Run the probes at regular intervals and fill in the table with the observed values. This helps you track changes over time and compare multiple endpoints. Below is a template you can use; replace the example values with your own measurements.

The table should include the endpoint URL, timestamp, solana-core version, number of features in the feature-set, presence of a specific feature, health status, current slot, and the cluster's highest slot. You can also add a column for the difference between the node's slot and the cluster's highest slot to quickly spot lag.

• Endpoint URL: e.g., https://api.mainnet-beta.solana.com
• Timestamp: ISO 8601 format.
• solana-core version: from getVersion.
• Feature count: number of keys in feature-set.
• Feature X present: yes/no.
• Health: 'ok' or error.
• Node slot: from getSlot.
• Cluster highest slot: from getClusterNodes or other source.
• Slot difference: node slot - cluster highest slot.

Limitations and Tradeoffs of Advertised Capabilities

The feature-set returned by getVersion is the node's own report and may not reflect the cluster's active set if the node is behind or misconfigured. A node could advertise a feature but still fail to process transactions that use it due to internal errors or incomplete synchronization. Additionally, some RPC methods are gated by node configuration rather than feature gates; for example, an operator might disable certain methods for security or performance reasons. This behavior is documented / varies by node, so you cannot assume that a method is available just because the feature is present.

Another limitation is that load-balanced endpoints may route requests to different nodes with different versions. A single getVersion call might hit one node, while a subsequent transaction is sent to another. To mitigate this, you should either use a dedicated endpoint or perform capability checks on each request, though the latter adds overhead. For production systems, consider using a provider that offers consistent node versions across regions, such as those described in RPC pricing.

• Advertised feature-set is node's self-report; may lag cluster.
• Method availability can be gated by config, not just features.
• Load balancers may route to different versions.
• Dedicated endpoints or per-request checks reduce risk.

Troubleshooting Common getVersion and Feature-Set Issues

If getVersion returns an error, the endpoint may be down or not a Solana RPC node. Check the URL and ensure it supports JSON-RPC 2.0. If the feature-set is empty or missing expected features, the node may be running an older version or not fully synced. In that case, compare with getClusterNodes to see the cluster's version distribution. If your node is the only one missing a feature, it is likely outdated.

If you receive a 'method not found' error when calling a method that should be available, verify that the method is not gated by configuration. Some providers disable certain methods by default. Also, ensure you are using the correct method name and parameters. For versioned transactions, check that the node supports the required feature and that your transaction is properly formatted; see Solana versioned transactions and getBlock parsing for details.

• Error from getVersion: endpoint may be down or invalid.
• Empty feature-set: node may be outdated or unsynced.
• Method not found: could be config-gated or version mismatch.
• Check method name and parameters; consult provider docs.

Next Steps: Integrating Capability Checks into Your Workflow

To ensure reliability, integrate capability checks into your application's startup and periodic health checks. Cache the capability record per endpoint and refresh it every few minutes or before critical operations. Use the results to decide whether to proceed with a transaction or fall back to a different endpoint. For a broader overview of Solana RPC, see the Solana API guide (RPC Assistant) and the OnFinality Learn hub.

If you are building a service that depends on specific features, consider using multiple RPC providers and load balancing based on capability. OnFinality offers Solana API endpoints with consistent versions and API service for reliable access. Always test your integration against the latest cluster features and monitor for changes.

• Cache capability record per endpoint; refresh regularly.
• Use checks before critical transactions.
• Consider multiple providers for redundancy.
• Monitor cluster feature activations and upgrade timelines.