Solana’s offline-signing proposal would keep approvals valid after failed transactions

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.

The migration guide describes moving native SOL into the derived address, transferring token balances into accounts controlled by it, and moving mint or freeze permissions to it. Stake accounts can move the staker authority, withdraw authority or both, depending on the permission being migrated. These are separate controls, rather than one universal wallet switch.

The Foundation proposes completing those handoffs while legacy durable nonces still work. For an affected treasury, approving the new signing software is therefore only part of the job. Its account inventory and the permissions each key currently holds determine what must change.

The two candidate designs also handle native SOL differently. Programmatic Signer’s derived SOL account is System-owned and can send SOL through an approved ordinary transfer. Vector initializes a program-owned account and releases SOL through its own authorized withdrawal or closing operation.

The implementation choice affects how tightly an approval constrains the transaction around it.

Programmatic Signer’s message documentation says the cold signatures bind the executor, nonce account and embedded execution message. A relayer cannot alter those authorized bytes while retaining valid signatures. It can, however, choose the outer fee payer and blockhash and add instructions before or after the submission.

Vector commits to the top-level instruction buffer, including the data and accounts used to pass approved actions into other programs. Instructions surrounding those actions must already be included when the cold key signs. A relayer cannot insert, remove or reorder them afterward without invalidating the approval.

Programmatic Signer allows an execution context to be assembled around an approved action; Vector requires the surrounding instruction sequence to be approved in advance. In both cases, paying for broadcast does not grant permission to rewrite the signed action.