Solana Plan Would Preserve Offline Approvals After Failures

The Solana Foundation is proposing signer programs to replace durable-nonce transactions used by exchanges, custodians and treasury operators. The programs would verify an offline signature and execute its approved instructions after an online relayer submits the transaction and pays the network fee.

The Foundation has not set a date to remove durable nonces or selected between Anza’s Programmatic Signer and Blueshift’s Vector. It has proposed a migration period of about six months, conditional on a replacement being audited, deployed on mainnet and ready for use. Durable nonces remain available.

The proposal would change the custody structure. A program-derived address, or PDA, would control the relevant SOL, tokens or permissions. A PDA has no private key; its authority would come from the signer program’s verification of the original cold-key approval.

Creating a PDA would not transfer funds or permissions. Operators would have to move SOL and token balances to accounts controlled by the PDA. They would also need to transfer permissions such as minting, freezing, staking and withdrawal authority. Stake accounts can have separate staker and withdrawal authorities, which may require separate migrations.

The two proposed systems use different structures for SOL. Programmatic Signer uses a System-owned derived account that can send SOL through an approved transfer. Vector uses a program-owned account and releases SOL through an authorized withdrawal or closing operation.

Durable nonces allow an offline signer to approve a transaction using a stored nonce instead of a recent blockhash that expires after a limited period. A transaction that passes validation but fails during execution can still consume its durable nonce, preventing the approval from being used again.

Programmatic Signer and Vector are designed to roll back the nonce update when execution fails. That can leave the signed approval available for another attempt. Vector’s documentation warns that a relayer could delay a transaction or that a signature exposed during a failed attempt could be used later. A deadline in the signed instructions can limit that risk. Revocation would require a separately authorized nonce advance.

The designs differ in what a relayer can change. Programmatic Signer binds the cold-key signature to an executor, a nonce account and an embedded execution message. A relayer can choose the fee payer and recent blockhash and add instructions outside the authorization, but cannot change the approved message.

Vector commits the top-level instruction buffer, including the data and accounts used to send approved actions to other programs. Instructions surrounding the approved action must be included before signing. Adding, removing or reordering them later would invalidate the approval.

Compatibility with other applications is a separate issue. The signer program would call those applications through cross-program invocation, or CPI. An application that accepts only direct instructions or cannot inspect actions nested inside another program could reject a valid approval. Token-2022’s CPI Guard restricts some transfers, burns, approvals and ownership changes through CPI.

The Foundation says replacing durable-nonce handling with ordinary recent-blockhash transactions would simplify validator processing. Solana’s 200-millisecond slot upgrade reached its final mainnet stage on Oct. 9. Faster block production leaves less wall-clock time for ordinary blockhash-based approvals, although blockhash expiry depends on block production rather than a fixed timer.

During a March 4 discussion, Michael, who identified himself as being from Fireblocks, supported ending durable nonces but raised concerns about CPI-based migration, contract dependence and DeFi compatibility. Grant, who identified himself as being at Unit 410, said a small, auditable signer program could support authority migration and opposed temporarily moving assets to a hot signer.

Programmatic Signer’s documentation reports a devnet deployment and audits in progress, with changes required before a version-one release or mainnet deployment. Vector publishes implementation code and program IDs, but its documentation does not state an audit or mainnet deployment status. Fireblocks’ current onboarding material still describes durable-nonce injection for selected WalletConnect integrations, including Jupiter and Kamino.