{"id":14393,"date":"2026-10-12T17:26:50","date_gmt":"2026-10-12T17:26:50","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=14393"},"modified":"2026-10-12T17:26:50","modified_gmt":"2026-10-12T17:26:50","slug":"solana-offline-signing-proposal-approvals-survive-failure","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=14393","title":{"rendered":"Solana offline-signing proposal: approvals survive failure"},"content":{"rendered":"

<\/p>\n

\n

Solana\u2019s 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\u2019s approval and execution.<\/p>\n

The Solana Foundation\u2019s 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.<\/p>\n

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.<\/p>\n

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

The key keeps approving, but the account changes<\/h2>\n

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.<\/p>\n

Solana\u2019s 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\u2019s earlier coverage examined that timing change; the nonce proposal concerns the architecture used to avoid the short approval window.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Solana doubles block production speed to 200ms as network prepares for Alpenglow upgrade<\/h3>\n<\/p>\n

<\/span> <\/div>\n

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\u2019s derived address as signer.<\/p>\n

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

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.<\/p>\n

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.<\/p>\n

The two candidate designs also handle native SOL differently. Programmatic Signer\u2019s 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.<\/p>\n

\"Proposed\"Proposed<\/p>\n

What the cold signature lets a relayer do<\/h2>\n

The implementation choice affects how tightly an approval constrains the transaction around it.<\/p>\n

Programmatic Signer\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n