okay so I need to talk about something that genuinely caught me off guard during #100DaysOfSolana and I feel like nobody explains it properly so here we go

you know how in Web2, if you build an API call and it fails, you just... retry it? same request, same body, send again. worst case you get a duplicate, you handle it with idempotency keys, whatever the request itself doesn't have an expiry date baked in

Solana transactions have an expiry date baked in

like structurally. at the protocol level. you cannot opt out of it

let me explain because this is actually kind of wild

the blockhash thing

every Solana transaction contains something called a recent blockhash. it's a 32-byte hash of a recent block, and it's required you literally cannot construct a valid transaction without one

const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();

const tx = await pipe(
  createTransactionMessage({ version: 0 }),
  m => setTransactionMessageFeePayerSigner(sender, m),
  m => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m), // 👈 this
  // ...
);

that latestBlockhash you fetched? it's valid for approximately 150 slots

slots happen every ~400 milliseconds

150 × 400ms = 60 seconds

your transaction has roughly 60-90 seconds to land on the network before it is permanently dead. not retryable. not recoverable. you need to build a brand new transaction with a fresh blockhash

why does this exist though

Okay here's where it gets interesting

The blockhash serves two purposes simultaneously and they're both actually really smart:

1. it proves the transaction is fresh

If there was no expiry, someone could intercept your signed transaction and replay it weeks later. the blockhash ties your transaction to a specific point in time after ~150 slots, that blockhash is no longer considered valid, so the transaction dies even if someone tries to resubmit it

2. It prevents literal duplicate transactions

Imagine you send 0.1 SOL to someone. the transaction looks identical to the last time you sent 0.1 SOL to that same person. without the blockhash, the network would have no way to tell "did this already happen or is this a new send?" WITH the blockhash, every transaction is unique because it references a specific recent block

so like... it's doing the job of a CSRF token AND an idempotency key AND a TTL all in one field. that's kind of a lot of work for 32 bytes

what this looks like when it goes wrong

Here's the scenario that'll get you: you build a transaction, get a blockhash, do some other stuff (UI interactions, user confirmations, whatever), and THEN try to send it

// ❌ bad pattern : time passes between fetch and send
const { value: blockhash } = await rpc.getLatestBlockhash().send();

await waitForUserToClickConfirm(); // this takes 2 minutes
await doSomeOtherAsyncThing();     // and this takes another minute

// by here? blockhash might be expired already
const signature = await sendTransaction(signedTx);
// TransactionExpiredBlockheightExceededError 💀

the fix is to fetch the blockhash as late as possible — right before you sign and send, not when you start building

// ✅ fetch blockhash late, sign, send immediately
const tx = buildTransactionWithoutBlockhash(sender, recipient, amount);

// fetch RIGHT before sending
const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();
const txWithBlockhash = setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx);
const signed = await signTransactionMessageWithSigners(txWithBlockhash);

// send immediately after signing
const signature = await rpc.sendTransaction(
  getBase64EncodedWireTransaction(signed),
  { encoding: "base64" }
).send();

minimize the gap between "I got a blockhash" and "I sent the transaction"

and if it expires mid-flight?

sometimes the transaction reaches the network but confirmation takes longer than the blockhash window. this happens more on mainnet under load

the network will eventually return TransactionExpiredBlockheightExceededError and you need to handle this explicitly:

try {
  // wait for confirmation
  const status = await waitForConfirmation(signature);
} catch (err) {
  if (err.message.includes('BlockheightExceeded')) {
    // the transaction is dead, not pending
    // you need to rebuild with a fresh blockhash and try again
    console.log('Transaction expired rebuilding with fresh blockhash');
    return await sendTransfer(sender, recipient, amount); // retry the whole thing
  }
  throw err; // different error, rethrow
}

the key thing: TransactionExpiredBlockheightExceededError is NOT a "try again with the same transaction" situation. that transaction is gone. you build a new one

the thing that makes this different from everything else

In literally every other system I've worked with, "retry" means "resend the same thing"

In Solana, retry means "construct a new thing that does the same action"

your signed transaction isn't a reusable object : it's a snapshot tied to a specific moment in time. once that moment passes, the snapshot is invalid. you're not retrying a request, you're making a new one that happens to do the same thing

This is a mental model shift that took me a minute to actually internalize because it runs against every HTTP instinct I have

tldr

• every Solana transaction embeds a recent blockhash that expires in ~60-90 seconds
• this is on purpose, it prevents replay attacks and duplicate transactions
• fetch the blockhash as late as possible before signing and sending
• if a transaction expires, don't retry it, rebuild it from scratch with a fresh blockhash
• TransactionExpiredBlockheightExceededError = make a new transaction, not send the old one again

the more I learn about Solana's design decisions the more I realize how much thought went into things that feel annoying at first, this being a perfect example. The expiry isn't a bug, it's load-bearing

Anyway that's what got me this week 🙂

Epoch 1 of #100DaysOfSolana. Writing about the things that actually surprised me so the next person is slightly less confused.

#100daysofsolana #solana #web3 #blockchain