Why does my Solana transaction have a signature but never confirm?

The result is the first signature embedded in the transaction, which exists before sending; it proves nothing about processing. The transaction was dropped before a leader processed it, or processed on a fork that was abandoned. Rebroadcast until the blockhash expires.

When is it safe to re-sign a Solana transaction?

Only once the block height has passed the lastValidBlockHeight of the blockhash you originally signed with; before that, the first transaction can still land.

Does a higher priority fee fix a transaction that is not landing?

Only when the transaction reached a leader and lost out to others. It does not help a transaction that was dropped on the way, or one with an expired blockhash.

Should I set skipPreflight to true to land faster?

Solana's guide recommends keeping it false. Skipping it saves the check but hides errors, so a broken transaction looks like a dropped one. Skip it only after simulating yourself.

Solana transaction not landing: how to diagnose it

Last updated: November 1, 2026

Endpoint and plans: Solana RPC endpoint.

Terms on this page: Recent blockhash · Block height · Priority fee.

At a glance

Symptom details
Property	Value
What sendTransaction's signature means	Accepted for forwarding — not processed, not confirmed
Blockhash lifetime	150 blocks; lastValidBlockHeight marks the last valid block height
Default preflight	Signature verification, blockhash recency and simulation
maxRetries	Overrides the RPC node's default retry logic; 0 lets you rebroadcast yourself
Safe to re-sign	Only after the original blockhash has expired

What you see

sendTransaction answers with a signature and no error. Afterwards getTransaction keeps returning null for that signature, no explorer shows it, and nothing ever reports a failure.

Why this happens

Solana's guide to retrying transactions lists how a transaction gets lost. Before processing, it can be dropped through UDP packet loss, network congestion that overwhelms validators, inconsistencies inside an RPC pool, or by referencing a blockhash that exists only on a lagging minority fork. After processing, it is lost if the cluster switches away from the minority fork it was processed on. Every transaction carries a recent blockhash and expires after 150 blocks; the lastValidBlockHeight returned by getLatestBlockhash marks the last block height at which it can still be included. By default sendTransaction runs preflight checks — signature verification, blockhash recency and a simulation — and then "immediately succeeds, without waiting for any confirmations". Without maxRetries, the node retries sending "until it is finalized or until the blockhash expires"; maxRetries overrides that.

What the signature tells you

Run getSignatureStatuses, compare getBlockHeight with lastValidBlockHeight, then read across
Signature status	Block height	What happened	Next move
err is set	Any	It landed and failed. Fees were paid	Read the logs; not a delivery problem
confirmed or finalized, no err	Any	It landed	Done. If a client timed out, it was the client
null	At or below lastValidBlockHeight	Not processed yet, or dropped	Resend the same bytes
null	Above lastValidBlockHeight	Expired. It can never land	Rebuild with a new blockhash, then check your fee

What to do

Sort the failure first with the table above: most of the fixes below only apply to one row.
Keep preflight on (skipPreflight false) so signature, blockhash and simulation errors come back immediately instead of as a silent drop.
Record lastValidBlockHeight together with the blockhash you signed with, and poll getBlockHeight against it.
Rebroadcast the same signed transaction while the blockhash is still valid; if you rebroadcast yourself, set maxRetries to 0 so the node does not also retry.
Re-sign with a fresh blockhash only after the old one has expired — until then the original transaction can still land.
If transactions keep expiring, look at inclusion: check the priority fee against recent fees for the accounts you write to, and set a compute unit limit close to what the transaction uses. A transaction that requests too much compute costs more, and a price of zero on a contended account rarely wins.
Fetch the blockhash at confirmed commitment and set preflightCommitment to match, so preflight does not simulate against a bank older than your hash.

When this is not our problem

Dropped packets, minority forks and blockhash expiry are properties of how Solana moves transactions to leaders, and they affect every RPC node, whoever operates it, Triport included. Only the client can rebroadcast or re-sign.

FAQ

Why does my Solana transaction have a signature but never confirm?: The result is the first signature embedded in the transaction, which exists before sending; it proves nothing about processing. The transaction was dropped before a leader processed it, or processed on a fork that was abandoned. Rebroadcast until the blockhash expires.
When is it safe to re-sign a Solana transaction?: Only once the block height has passed the lastValidBlockHeight of the blockhash you originally signed with; before that, the first transaction can still land.
Does a higher priority fee fix a transaction that is not landing?: Only when the transaction reached a leader and lost out to others. It does not help a transaction that was dropped on the way, or one with an expired blockhash.
Should I set skipPreflight to true to land faster?: Solana's guide recommends keeping it false. Skipping it saves the check but hides errors, so a broken transaction looks like a dropped one. Skip it only after simulating yourself.