POST
/
9de47db917d4f69168e3fed02217d15b
getLatestBlockhash
curl --request POST \
  --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b \
  --header 'Content-Type: application/json' \
  --data '{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getLatestBlockhash",
  "params": [
    "<any>"
  ]
}'
{
  "jsonrpc": "<string>",
  "id": 123,
  "result": {
    "blockhash": "<string>",
    "feeCalculator": {
      "lamportsPerSignature": 123
    }
  }
}
The Solana getLatestBlockhash method returns the latest block hash that’s usable for a new transaction. This method provides the latest block hash, which is required for creating a new transaction. It is useful for creating new transactions that are valid for inclusion in the ledger. See also Understanding the difference between blocks and slots on Solana.
Get you own node endpoint todayStart for free and get your app to production levels immediately. No credit card required.You can sign up with your GitHub, X, Google, or Microsoft account.

​
Parameters

This method does not require any parameters.

​
Response

  • slot — the slot number; note slots and blocks are different entities.
  • blockhash — the hash of the block that’s produced in the slot number returned.
  • lastValidBlockHeight — the block (not slot!) height number until which the transaction is considered valid and after which it will expire. The lastValidBlockHeight is always the current block (again, not slot!) number plus 150 blocks. See the example below for a walkthrough explanation.

​
Use case

A practical use case for getLatestBlockhash is to create new transactions that are valid for inclusion in the ledger. This can be useful for wallets or other applications that need to create new transactions. A pending transaction is considered valid to be committed to the chain for 150 blocks before it expires and gets dropped by nodes.

​
Further explanation & a walkthrough

Let’s get a walkthrough as the difference between slots and blocks (especially in numbers) can be confusing. A slot is a scheduled spot for a validator to be produce a block. The current gap (as of January 1, 2025) between slot numbers and block numbers is pretty significant—about 22 million of empty slots. January 1, 2025 numbers for reference:
  • Slot height: 311118891
  • Block height: 289445888
For illustration, let’s make a getLatestBlockhash call that we are describing here:
Shell
 % curl https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b -s -X POST -H "Content-Type: application/json" -d '
  {
    "id":1,
    "jsonrpc":"2.0",
    "method":"getLatestBlockhash",
    "params":[
      {
        "commitment":"processed"
      }
    ]
  }
' | jq '.'
{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "apiVersion": "2.0.18",
      "slot": 311115149
    },
    "value": {
      "blockhash": "AAU3aKZUQbddu7Q6sP8sggmQme7B9H1FAZvjVvkz5MZq",
      "lastValidBlockHeight": 289442306
    }
  },
  "id": 1
}
Again, note that the slot number "slot": 311115149 and "lastValidBlockHeight": 289442306are about 22 million blocks apart. If you are learning the Solana inner workings and check block 289442306 in the explorer, you will see that the block until which your pending transaction is supposed to stay valid is about 4 months in the past from the time of the call. How is that possible? A transaction lives in the pool of pending transactions before it gets picked up by a validator for 150 blocks (not slots!) before it gets dropped. So when doing a getLatestBlockheight call, you get the lastValidBlockHeight value that is determined by the current block height (current latest block at the time of the call, and not the slot height) + 150 blocks. For our example, let’s do a getBlock call, the naming of which confuses things even further as you actually need to provide the slot number as a value in the getBlock call:
Shell
 % curl --request POST \
     --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/ \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getBlock",
  "params": [
    311115149,
    {
      "encoding": "jsonParsed",
      "maxSupportedTransactionVersion": 0
    }
  ]
}
' | jq '.'
{
  "jsonrpc": "2.0",
  "result": {
    "blockHeight": 289442156,
    "blockTime": 1735703553,
    "blockhash": "AAU3aKZUQbddu7Q6sP8sggmQme7B9H1FAZvjVvkz5MZq",
This is where you’ll see the slot to block numbers mapping:
  • "params": [311115149
  • "blockHeight": 289442156
For our example: 289442156 - 289442306 = 150. So this checks out. You can get the current block (not slot!) height with the getBlockHeight call. And you can get the current slot height with the getSlot call. So, to it all sum up:
  • Online Solana explorers incorrectly name slots as blocks in the URL, in description, or both:
  • Slots and blocks have a mapping. The incorrectly named method getBlock actually fetches you a slot. And the fetched slot contains the actual block number in that slot and all the block data like hash, time, transactions etc.
  • You can get the latest slot number (slot height) with the getSlot call.
  • You can get the latest block number (block height) with the getBlockHeight call.
  • Validators use the actual block numbers and not slot numbers when determining whether your transaction is still valid to be included in the chain or not. This means when the chain has an empty slot with no block produced in the slot, it’s not going into the validator transaction inclusion calculations, because (again) only 150 blocks are considered and not slots.

Body

application/json

Response

200 - application/json

Latest blockhash details

The response is of type object.