Solana Foundation is weighing how to retire durable nonces, the mechanism that lets a cold key approve a transaction offline and broadcast it later. The replacement would keep that ability, but it moves control of affected accounts to a program-derived address. For exchanges, custodians and treasury teams, that changes who signs, what applications see, and which permissions must move.
What changes under the proposal
Durable nonces solve a timing problem. A transaction tied to a recent blockhash expires quickly. An offline signer can approve one using a stored nonce, so approval and broadcast happen at different times. Solana’s 200ms slot upgrade reached its final mainnet stage on Oct. 9, leaving less room for ordinary blockhash approvals.
Under the plan, onchain signer programs verify an offline signature and execute the approved instructions. The cold key still authorizes actions. A separate online operator submits them and pays the network fee. A PDA controlled by the signer program controls the affected accounts. It has no private key. Its authority comes from the program verifying the original key’s approval. Deriving that address does not move assets or permissions.
Operators would need to move native $SOL, token balances, mint or freeze permissions, and stake authorities where relevant. These are separate controls. The Foundation suggests completing handoffs while legacy durable nonces still work. It has not set a removal date or chosen between Anza’s Programmatic Signer and Blueshift’s Vector. The roughly six-month window depends on a suitable replacement being audited and live on mainnet.
Relayers, retries, and signed approvals
Programmatic Signer has the cold key sign an authorization message, not the transaction sent to the network. A relayer places that approval in a fresh-blockhash transaction. The signer program verifies the message and executes the approved instructions. Vector commits to the top-level instruction buffer, so surrounding instructions must be included when the cold key signs. In both designs, paying for broadcast does not grant permission to rewrite the signed action.
Failed execution is another difference. A current durable-nonce transaction that passes validation but fails during execution still consumes its nonce. Programmatic Signer commits the nonce advance and application changes together, or rolls them back together. Vector documents similar retry behavior. That means a failed submission may not invalidate the approval. Vector warns a relayer could withhold a transaction until conditions change, or an exposed signature could execute later. A timeout inside the signed instructions can reject execution after a deadline. Revocation requires a separately authorized nonce advance.
Applications and migration hurdles
Applications would receive approved actions through cross-program invocation, or CPI. Checks that inspect only top-level repayment or signature verification can miss nested calls. Token-2022’s CPI Guard adds rules: CPI transfers and burns require delegate authority, CPI approvals are prohibited, and changing the owner is prohibited even outside CPI. Programmatic Signer reports devnet deployment and audits in progress. Vector publishes code, but its README does not state audit or mainnet status. A production migration needs audited mainnet code and app paths that preserve approval controls.
