Solana method
getVersion
Returns the solana-core version and feature set of the node.
How each provider handles it
| Provider | Status | Success | Median |
|---|---|---|---|
| Tatum | Degraded | 97.4% | 27 ms |
| PublicNode | Supported | 100.0% | 25 ms |
| Solana Foundation | Supported | 99.7% | 14 ms |
Success excludes calls the provider does not implement — an optional method a provider declines to offer is a capability fact, not a failure, and is never scored as one.
Over time
Median latency per hour. Gaps are periods with no measurement, drawn as gaps rather than joined across — a line through missing data invents a measurement that was never taken.
Logarithmic scale — each gridline is ten times the one below it. Click a provider in the legend to hide it.
What it does
Reports the software version behind an endpoint, together with `feature-set` — a numeric identifier of the activated feature bundle the node is running.
Unlike Ethereum's client version string, this one is rarely rewritten by providers, so it is a reasonably reliable view of what software is actually serving.
Returns
Object with solana-core and feature-set.
Try it
Runnable as written, against a keyless public endpoint. Nothing here needs an API key.
Request
curl -s https://api.mainnet-beta.solana.com \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getVersion"}'As JSON-RPC
{
"jsonrpc": "2.0",
"id": 1,
"method": "getVersion"
}Response
{
"jsonrpc": "2.0",
"result": {
"solana-core": "2.1.11",
"feature-set": 3271415109
},
"id": 1
}Things that bite
- A node whose
feature-setdiffers from the cluster's is running a different activation set and can legitimately disagree about transaction outcomes.
Why it is measured
The cheapest Solana call, which makes it the baseline every other Solana latency figure is read against.
Called every 900 seconds per endpoint, with jitter so the fleet does not hit a provider in lockstep.
24h window · generated 2026-10-08 19:46:55 UTC · 3 providers