🕵️ SicherheitslückenWhatsApp-Schwachstelle: Zugriff auf Fotos bei gesperrtem Android-Handy(03.09.2026 um 09:18 Uhr)
🎥 PodcastsAuslegungssache 167: Datenschutz mit System(04.09.2026 um 06:10 Uhr)
🕵️ SicherheitslückenJetzt patchen! Es laufen derzeit Schadcode-Attacken auf Chrome(04.09.2026 um 08:48 Uhr)
🔧 AI Nachrichten What went wrong with Apple’s design group?(01.09.2026 um 13:34 Uhr)
🔧 AI Nachrichten Anthropic makes changes to stop AI agents running amok again(02.09.2026 um 03:47 Uhr)
🕵️ SicherheitslückenSerious vulnerability threatens tens of thousands of Exchange servers(03.09.2026 um 19:20 Uhr)
🕵️ SicherheitslückenWhatsApp-Schwachstelle: Zugriff auf Fotos bei gesperrtem Android-Handy(03.09.2026 um 09:18 Uhr)
🎥 PodcastsAuslegungssache 167: Datenschutz mit System(04.09.2026 um 06:10 Uhr)
🕵️ SicherheitslückenJetzt patchen! Es laufen derzeit Schadcode-Attacken auf Chrome(04.09.2026 um 08:48 Uhr)
🔧 AI Nachrichten What went wrong with Apple’s design group?(01.09.2026 um 13:34 Uhr)
🔧 AI Nachrichten Anthropic makes changes to stop AI agents running amok again(02.09.2026 um 03:47 Uhr)
🕵️ SicherheitslückenSerious vulnerability threatens tens of thousands of Exchange servers(03.09.2026 um 19:20 Uhr)

🔧 Programmierung 🕛 kürzlich 5 Min Lesezeit
0

Solana transactions expire and nobody warned me 💀

↗ Quelle (dev.to)
🗣️ Stimme:
📑 Inhaltsübersicht

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




CODE
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




CODE
// ❌ 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




CODE
// ✅ 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:




CODE
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

Vollständiger Original-Bericht
Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
↗ Original-Artikel auf dev.to lesen
Wie bewertest du diesen Beitrag?
1 Klick Feedback
Teilen mit Netzwerk & Team:

Community-Analysen & Experten-Meinungen 0

Verfasse deine eigene Analyse, teile Workarounds oder diskutiere diesen Vorfall im Blog.
Noch keine Community-Analyse verfasst. Markiere einen Textabschnitt oder klicke oben auf Eigene Analyse verfassen“!
Community Pulse: Relevanz-Einschätzung
1 Klick Experten-Votum
🔴 Akute Relevanz 53%
🟡 In Evaluierung 28%
🟢 Keine Auswirkung 14%
Spannende Innovation 5%
Verwandte Story-Cluster & Quellen (Vektor-KI)
Port 8095 Engine
2 Quellen
CVE-2026-23143 | Linux Kernel up to 6.18.6 drivers/net/virtio_net.c hash_key_data[] uninitialized pointer (Nessus ID 299319 / WID-SEC-2026-0421)
1 Quelle
ChatGPT showing blank screen [Fix]
1 Quelle
Sofort deinstallieren: Diese 19 Browser-Erweiterungen sind mit Malware verseucht
Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten Solana transactions expire and nobody warned me 💀

Thematisch verwandte Begriffe: Solana, transactions, expire, nobody · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...