Solana method
getLatestBlockhash
Returns a recent blockhash and the last block height at which it stays valid.
How each provider handles it
This method has not been measured in this window.
It is scheduled but no observation has landed yet.
What it does
Every Solana transaction must reference a recent blockhash. It serves as both a nonce and an expiry: a transaction whose blockhash is older than about 150 blocks is rejected outright.
That makes this call unavoidable and time-critical. A stale blockhash from a lagging provider gives the transaction a shorter usable life, and one that is too old fails immediately.
Parameters
configObjectoptionalcommitmentandminContextSlot.Default:finalized
Returns
Object with blockhash (base-58) and lastValidBlockHeight.
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":"getLatestBlockhash","params":[{"commitment":"processed"}]}'As JSON-RPC
{
"jsonrpc": "2.0",
"id": 1,
"method": "getLatestBlockhash",
"params": [{ "commitment": "processed" }]
}Response
{
"jsonrpc": "2.0",
"result": {
"context": { "apiVersion": "2.1.11", "slot": 372145830 },
"value": {
"blockhash": "EkSnNWid2cvwEVnVx9aBqawnmiCNiDgp3gUdkDPTKN1N",
"lastValidBlockHeight": 372145980
}
},
"id": 1
}Things that bite
- The real answer is under
result.value;result.context.slottells you which slot the node answered from. Most Solana methods have this envelope and callers routinely forget it. lastValidBlockHeightcounts blocks, not slots. Because slots are skipped, the two numbers drift apart and are not interchangeable.
Why it is measured
It sits on the critical path of every Solana transaction, so its latency is paid by every user of every application on the chain.
Called every 30 seconds per endpoint, with jitter so the fleet does not hit a provider in lockstep.
7d window · generated 2026-08-24 15:46:42 UTC · 0 providers