On this page
- Every Solana transaction includes a recent blockhash; once that blockhash is more than 151 blocks old, the transaction can never land.
- An expired transaction moves no tokens and pays no fee. Build a new one; do not re-sign the old bytes.
- Fianto builds each payment with a fresh blockhash, refuses to start one on a link with under two minutes left, and keeps rebroadcasting until the blockhash is past its last valid block.
What does "blockhash not found" mean?
"Blockhash not found" means the node checking your transaction cannot match its blockhash to a block it considers recent. A blockhash is the fingerprint of a recent block; every transaction carries one, and it does two jobs: it proves the transaction was made recently, and it lets the network spot the same transaction sent twice.
Two situations produce the message:
- The blockhash is too old. Solana's confirmation and expiration guide says: "Currently, Solana clusters require that transactions use blockhashes that are no more than 151 blocks old." A transaction with an older one is not processed.
- The blockhash is too new for the node. The same guide notes that a simulation run against an older block than the one the blockhash came from fails with this same error. This happens when an app takes its blockhash from one RPC node and checks the transaction on a node that is behind.
In a wallet or a payment page, the first case is the usual one: the transaction was built, then sat waiting for a signature.
How long is a Solana blockhash valid?
A Solana blockhash is valid for 151 blocks, which is the figure to rely on. The confirmation guide, read on 15 October 2026, converts that to "about 60 to 90 seconds", but it was written for the slot length Solana had before October 2026. The Alpenglow upgrade page says block time was cut separately, through shorter slots, in four stages that completed in October 2026, so the same 151 blocks now pass faster than that guide says.
Alpenglow itself, scheduled to activate on mainnet on 21 October 2026, replaces the voting that makes blocks final. On transactions the page says: "Execution is untouched: the SVM, transactions, programs, and fees stay the same." It gives no new figure for the blockhash window; what changes for finality is in confirmed vs finalized Solana payments. Until Solana's docs state a new figure, treat the expiry as a block count and track it with lastValidBlockHeight, the block height that getLatestBlockhash returns beside every blockhash. Once the chain passes that height, the transaction is dead.
Why do Solana payments expire while you wait to sign?
Solana payments expire while you wait because the blockhash is fixed when the transaction is built, before your wallet ever shows it to you. The clock starts at the build, not at your signature. Reading the amounts, switching wallet accounts or stepping away all spend blocks.
Solana's guide names the ideal: "The ideal scenario is that a recent blockhash is fetched right before a user signs their transaction." Payment pages differ in how close they get. On Fianto's checkout the transaction is built only when you press Pay or Subscribe with a wallet connected (if yours is missing from the list, see why a wallet does not show at checkout). A one-off payment opens the wallet straight after the build; a subscription first shows its rent and fees for you to approve, so the time you spend in the wallet is most of the blockhash's life.
What should you do if a payment expired before you signed?
If a payment expired before you signed, start again from a fresh transaction. On a Fianto checkout:
- Look at your wallet's recent activity. If no USDC left your account, nothing happened.
- Press Pay (or Subscribe) again. That builds a new transaction with a new blockhash.
- Approve it in the wallet without leaving the prompt open.
- If the page says the link itself has expired, ask the merchant for a new one. A checkout link has its own expiry, separate from the blockhash.
If you did sign and the page then reports a failure, the checkout says: "This payment did not complete. Check your wallet's recent activity first: if the USDC left your account, do not pay again, and contact [merchant name]. If it did not, press Pay to try again." Follow it in that order. Other reasons a payment stops are in why a Solana payment failed.
How does Fianto keep a blockhash from expiring mid-payment?
Fianto keeps a blockhash from expiring mid-payment by building late, refusing to build when there is too little time, and resending a signed transaction until its blockhash is certainly dead. These are the rules in Fianto's code, with the timings Fianto sets itself:
| Rule | What it does | What the payer sees |
|---|---|---|
| Fresh blockhash per build | Each build asks the network for the latest blockhash; two builds within one second share it | Nothing; the wallet opens with a current transaction |
| Two-minute floor | A checkout link with under 120 seconds left will not build a transaction | "This payment link expires in under 2 minutes, which is not enough time to finish paying. Nothing has been charged. Ask [merchant name] for a new payment link." |
| 30-second review on subscriptions | A subscription build whose review screen is not approved within 30 seconds is withdrawn before the wallet opens | "The prepared subscription was not approved in time, so nothing was sent. Press Subscribe to prepare it again." |
| 90-second limit in the portal | A cancel, rent reclaim or re-authorise built more than 90 seconds earlier is refused at submit | The action has to be started again |
| Rebroadcast until expiry | Fianto sends the signed transaction itself, then resends it every tracker pass while it is unseen | A payment that lands late still counts |
The first send runs with preflight on, so the network simulates the transaction before accepting it. Fianto keeps resending without preflight until the chain is 150 blocks past the transaction's lastValidBlockHeight; only then, and only if every RPC provider it uses says it has never seen the signature, does it mark the payment as dropped and let the customer pay again. A dropped payment costs the customer no fee at all; what each Fianto transaction costs when it does land is in how much a Solana transaction costs.
A hosted checkout that builds, sends and tracks the transaction for you.
See how the checkout worksWhy can't a checkout change while a payment might still land?
A checkout cannot change while a payment might still land because a signed transaction stays valid until its blockhash expires, whatever the page shows. Fianto records the lastValidBlockHeight of the latest build on each checkout session and never lowers it. Two actions wait for that height to pass:
- A merchant reissuing a session's link through the API, which gives the session a new URL. It answers
payment_until the last build's blockhash is dead.in_ progress - A customer applying or removing a discount code on the checkout, which changes the amount. A transaction signed at the old amount must not be able to land after the price moved.
Solana's retry guide gives the same rule to anyone resending payments: "Before re-signing any transaction, it is very important to ensure that the initial transaction's blockhash has expired." Re-signing earlier risks two transactions landing for one purchase. If you build your own Solana payment flow, compare the current block height with lastValidBlockHeight before you ever ask the customer to sign again. With Fianto that check is done for you; the payment lifecycle page in the docs follows a payment from build to settlement.