So following the answer from this thread:

How many solana transaction confirmations are enough to declare a transaction as finalized before it hits 31 and actually finalizes itself?

Solana doesn't work with the "number of confirmations" scheme that is used in Ethereum with PoW. The commitment levels are based whether a supermajority of validators has confirmed the transaction (finalized) or includes votes from gossip (inter-validator communication) and replay (confirmed). Therefore, the time to confirmed and time to finalized can vary.

and documentation from: https://docs.solana.com/developing/clients/jsonrpc-api#default

If commitment configuration is not provided, the node will default to "finalized" commitment

On the front-end, when sending transactions like so

const signature = await provider.signAndSendTransaction(transaction);

          const confirmation = await connection.confirmTransaction(
              blockhash: latestBlockHash.blockhash,
              lastValidBlockHeight: latestBlockHash.lastValidBlockHeight,

I would get the following RpcResponse object

 const confirmationRpcResponse = {
    context: {slot: 150669448}
    value: {err: null}

Is my understanding correct, that if I do not provide any commitment (in the signAndSendTransaction method) the RPC response confirmTransaction gives me information that transaction was finalized and I do not need any more "checking for confirmations", "checking for timestamps" etc. ?

Why does value key hold an err object and no actual value, like "processed" "finalized" "confirmed" - anything that would be more understandable than just slot and empty err key. How should I understand the response I got?

UPDATE 26.07.2022:

Just got the following error:

Error: TransactionExpiredBlockheightExceededError: Signature mySingature--->qYmvyL9qqsJte2TKXLyu9DZUrjQs9cU9PFVsyvjGM9vd3UykkvbLfLhbRjQqhM4BhRFWM7eW has expired: block height exceeded.

When using the above method. So there is definitely something else that has to be done before I can declare a transaction final. Where can I read about it?

UPDATE 27.07.2022:

So yesterday I was getting something from

              blockhash: latestBlockHash.blockhash,
              lastValidBlockHeight: latestBlockHash.lastValidBlockHeight,

Today it doesn't return anything. Just like that. good game well played. Looks like after some time I get:

Error: TransactionExpiredBlockheightExceededError: Signature 56767Ps4Fq4ZCaowEzPxPoNhSEECsw41MebNkSCEcx2ZnWmQr8aCQjTqnArSK7NeCqBXRUehNuiqQk2LRwhym73 has expired: block height exceeded.

So I guess the network is busy.

Follow-up after few minutes


Transaction has been confirmed, finalized! SuccessFinalizedMaximum Confirmations Achieved!

Can someone explain that to me?

signAndSendTransaction(transaction) -> doesn't return any promise next connection.confirmTransaction -> return an error that blockheight was exceeded. Then after a while transaction gets included.

How am I supposed to handle this on the front-end...

1 Answer 1


Reasons that confirmTransaction might throw a block height exceeded error when, in fact, the transaction was confirmed:

  • the signature is so old that it’s fallen out of the status cache. The confirm method does not search any further back in the ledger than that. Read more here.
  • the signature was confirmed before you made the call to confirmTransaction, so the confirmation code ‘missed’ it. This is a known bug, tracked here.

When the block height passes without confirmTransaction having received a notification that the signature was confirmed, for one of the above reasons, you may receive a misleading BlockHeightExceeded error.

  • As for the format of the response, where you have a null err property, you can read about that here: docs.solana.com/developing/clients/jsonrpc-api#results-31 Jul 28, 2022 at 6:36
  • Thank you @steveluscher. And is there any reason the response object doesn't include property confirmationStatus or confirmations? Could this be also related to the bug github.com/solana-labs/solana/issues/25955? Is there any workaround for the confirmTransaction error until the issue gets fixed? Jul 28, 2022 at 9:07
  • confirmations is nullable. The docs have this to say about that: “…null if rooted, as well as finalized by a supermajority of the cluster” Jul 28, 2022 at 21:56
  • With respect to confirmationStatus, the code comments have this to say: “cluster confirmation status, if data available.” Is this an old transaction; one that would have fallen out of the status cache of the RPC you're making the request to? Jul 28, 2022 at 22:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.