Solana Nears Offline-Signing Migration Amid Concerns Over Timing

Introduction

Solana's plan to retire durable nonces poses a challenge for exchanges, custodians, and treasury operators using the signing method. The proposed replacement adds a program between the cold key's approval and execution, changing which addresses control the affected assets.

Architecture Changes

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. This creates a different custody architecture, requiring operators to migrate the relevant assets or permissions, applications to accept actions arriving through another program, and risk teams to approve the new signing path.

Durable Nonces

The original durable nonces solve a timing problem by allowing approval and broadcast to happen at different times. Instead of signing a transaction tied to a recent blockhash that soon expires, an offline signer can approve one using a stored nonce. This approach is particularly useful for exchanges and custodians, which can use it to ensure timely and secure transactions.

Migration and Implementation

The Solana 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. The key keeps approving, but the account changes must be made to accommodate the new signing path. 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.

Comparison of Programmatic Signer and Vector

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. In contrast, 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.