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.

The key keeps approving, but the account changes

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.

What the cold signature lets a relayer do

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.

A failed execution attempt can leave a cold approval executable later. A current durable-nonce transaction that passes validation but fails during execution still consumes its nonce. Programmatic Signer’s architecture commits the nonce advance and application changes together, or rolls them back together. Vector documents the same ability to retry a failed action.

For operators, retryability means a failed submission has not necessarily invalidated the approval. Without an enforced deadline, it can remain available for later execution while its nonce is unchanged.

Vector explicitly warns that a relayer could withhold a transaction until conditions change, or that a signature exposed by a failed attempt could execute later. A timeout included in the signed instructions can reject execution after a deadline. Revocation requires a separately authorized nonce advance to land. A deadline rejection itself does not consume a nonce whose changes roll back with the failed transaction.

Application access is a separate custody test

The Foundation’s rationale is to simplify validator handling. Durable nonces require special replay-prevention rules, complicate asynchronous execution and make invalid transactions harder to filter. Moving approval and replay state into ordinary programs leaves validators processing normal blockhash transactions.

Applications then receive approved actions through cross-program invocation, or CPI: one program calls another. That can conflict with an application’s rule that an action must arrive directly as a top-level instruction. Checks that inspect only top-level repayment or signature-verification instructions can also miss an action nested inside the signer program.

More available call depth does not resolve a rule that rejects the call’s position or cannot inspect the nested instructions. The Foundation suggests supporting known signer programs or offering another execution path. Whether an application accepts a PDA’s signature is consequently a different question from whether the offline approval is cryptographically valid.

Token-2022’s CPI Guard shows why compatibility needs a precise account-level assessment. With the guard enabled, CPI transfers and burns require delegate authority; approvals through CPI are prohibited, and changing the owner is prohibited even outside CPI. Permanent delegates have transfer and burn exceptions.

Those rules are more specific than a blanket ban on every PDA action. A delegate-based transfer route may exist, but establishing or using that authority introduces its own permission and custody-policy decision.

Institutional concerns raised in March centered on application access and the controls under which funds may move. In the March 4 discussion, a participant identifying himself as Michael from Fireblocks supported nonce deprecation while objecting to CPI Passthrough’s migration, contract dependence and DeFi compatibility burdens. He favored transaction envelopes, with Sudo as an alternative, rather than the proposed CPI-based signing path.

Grant, who identified himself as being at Unit 410, said the same day that a small, auditable signer program might make authority migration acceptable. He rejected a workaround that temporarily moves assets to a hot signer, even for an atomic operation, because funds must remain associated with cold storage in its noncustodial model.

A testable design still needs a production migration path

Programmatic Signer’s current documentation reports devnet deployment and audits in progress, with remediation required before its v1 release and any mainnet deployment. Its interfaces may change. The usage documentation still marks simulation and relay submission as coming soon, while several migration operations are similarly unfinished in the guide.

Vector publishes implementation code and program IDs; its README does not state an audit or mainnet deployment status.

Meanwhile, Fireblocks’ current protocol onboarding kit still describes automatic durable-nonce injection for selected WalletConnect integrations, including Jupiter and Kamino, with a default provider-managed 15-minute validity window. That describes an existing approval workflow which a replacement must accommodate.

An operational migration needs an audited mainnet replacement, usable tools and application paths that retain each operator’s approval controls.