Solana’s plan to retire durable nonces, which let transactions be signed offline and broadcast later, would preserve cold-key approval while changing which addresses control the affected assets. For exchanges, custodians and treasury operators using that signing method, the proposed replacement adds a program between the cold key’s approval and execution.

The Solana Foundation’s October deprecation plan points to onchain signer programs that verify an offline signature and execute its approved instructions. A program-derived address, or PDA, would control the affected accounts. The original key would still authorize actions, while a separate online operator submits them and pays the network fee.

The replacement creates a different custody architecture: operators must migrate the relevant assets or permissions, applications must accept actions arriving through another program, and risk teams must approve the new signing path.

Durable nonces remain usable. The Foundation has not set a removal date or made a final choice between Anza’s Programmatic Signer and Blueshift’s Vector. Its roughly six-month migration window is conditional on a suitable replacement being ready, audited and live on mainnet.

Durable nonces solve a timing problem. Instead of signing a transaction tied to a recent blockhash that soon expires, an offline signer can approve one using a stored nonce. That allows approval and broadcast to happen at different times.

Solana’s separate 200ms slot upgrade reached its final mainnet stage on Oct. 9. Faster block production leaves less wall-clock time for ordinary blockhash-based approvals, although expiry depends on block production rather than a guaranteed timer. CryptoSlate’s earlier coverage examined that timing change; the nonce proposal concerns the architecture used to avoid the short approval window.

Under Programmatic Signer , the cold key signs an authorization message rather than the transaction sent to the network. A relayer places that approval in a fresh-blockhash transaction. The signer program verifies the authorization and executes the approved instructions with the key’s derived address as signer.

The PDA has no private key of its own. Its ability to act comes from the signer program verifying the original key’s approval. Deriving the address does not move any assets or permissions: those must be transferred separately.