Last Valid Block Height

Overview

Last valid block height commonly appears in Solana transaction workflows. When an application fetches a recent blockhash, the response includes a height after which transactions using that blockhash are considered expired and should not be accepted.

The value is a block height, not a wall-clock timestamp and not necessarily a slot number. Network progress determines the available submission window. A transaction may still fail earlier for fees, account state, signatures, or program errors. Clients should retain the blockhash and its matching last valid block height together, poll signature status, and compare current block height before retrying. After expiry, they must obtain a fresh blockhash and re-sign because the signed message changes. Re-broadcasting an expired serialized transaction cannot restore validity. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. User-facing status should describe what is known without overstating settlement.

Last Valid Block Height should be represented as a sequence of observable states rather than one success flag. Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available. Implementations need idempotent processing keyed to stable transaction and business identifiers. Practical implication: Last valid block height bounds a transaction’s usable blockhash window, requiring fresh construction and signatures after expiration.