Solana is moving to overhaul its offline transaction signing architecture, proposing to replace “durable nonces” to enhance security and operational efficiency for institutional users. The Solana cold wallet migration was outlined by the Solana Foundation in its October deprecation plan, which aims to create a new program layer between cold-key approvals and fund execution.
This critical update addresses complexities stemming from the network’s recently accelerated block times.
This initiative follows Solana’s successful final mainnet implementation of a 200-millisecond slot upgrade on October 9. While durable nonces currently allow offline transactions to be signed and broadcast later, the faster block production has amplified a timing problem that limits the window for blockhash-based approvals. The proposed replacement seeks to mitigate these issues by introducing an onchain signer program architecture.
Rethinking Solana’s Cold Wallet Migration Paradigm
Under the new design, a program-derived address (PDA) will manage the affected accounts, allowing the original cold key to authorize actions while a separate online operator handles submission and network fees.
This creates a distinct custody model that requires operators to migrate assets and permissions, and applications to adapt to actions routed through a new program. Risk teams will also need to approve the updated signing path.
The core issue durable nonces aimed to solve was a timing challenge: enabling an offline signer to approve a transaction using a stored nonce, rather than a rapidly expiring recent blockhash. This allowed for separation between transaction approval and its eventual broadcast to the network.
However, the recent network upgrades have significantly shortened block production times, intensifying the need for a more robust and adaptable solution.
The Solana Foundation’s October deprecation plan outlines the move towards onchain signer programs. These programs are designed to verify an offline signature and then execute its approved instructions. This fundamental shift means that while the original cold key still authorizes actions, a program-derived address (PDA) takes control of the associated accounts.
The mechanics of the proposed solutions
The new architecture positions a program between the cold key’s approval and the transaction’s execution. This preserves the security benefits of cold storage while delegating the responsibility of transaction submission and fee payment to an online operator. It’s a re-imagining of how security is maintained in a high-speed blockchain environment.
Crucially, a PDA possesses no private key of its own; its authority to act is derived solely from the signer program verifying the original key’s approval. This design ensures that the cold key remains the ultimate arbiter of actions. However, deriving an address does not automatically move assets or permissions; these require separate, deliberate transfers.
Migration challenges for operators
Implementing this new system isn’t a simple flip of a switch for entities like exchanges and custodians. Operators must undertake a comprehensive migration of relevant assets and permissions. This includes moving native SOL, transferring token balances into accounts controlled by the PDA, and reassigning mint or freeze permissions.
Stake accounts also face adjustments, potentially needing to migrate staker authority, withdrawal authority, or both. These are not universal wallet switches but rather granular controls that demand careful planning and execution. The Solana Foundation suggests completing these handoffs while legacy durable nonces are still functional, easing the transition period.
Differentiating Programmatic Signer and Vector
The Solana Foundation has yet to make a final selection between two prominent candidate designs for this new architecture: Anza’s Programmatic Signer and Blueshift’s Vector. Both solutions aim to fulfill the objectives of the deprecation plan, but they approach the intricacies of cold signature control and transaction construction with distinct methodologies.
Understanding these differences is crucial for institutional users who will eventually need to integrate one of these systems. Each design offers a unique balance of flexibility and control over the transaction execution process, impacting how operators assemble and manage their approved actions on the network.
Granular control and replay state
Programmatic Signer, developed by Anza, specifies that a cold signature binds the executor, nonce account, and the embedded execution message. This design grants the relayer flexibility to add outer fee payers, blockhashes, and additional instructions before or after the authorized core message. The cold signature strictly protects the authorized bytes within the embedded message.
Conversely, Blueshift’s Vector commits the cold approval to the entire top-level instruction buffer, encompassing data and accounts used to pass actions to other programs. This means all surrounding instructions must be pre-approved during the initial signing. A relayer cannot alter, insert, or reorder these instructions post-signing without invalidating the approval, offering a more rigid but potentially more secure constraint.
Implications for transaction retryability
A key enhancement offered by both proposed solutions is the ability to retry failed transactions without invalidating the original approval. Under the current durable nonce system, a transaction that passes validation but fails during execution still consumes its nonce, preventing an automatic retry of the same signed action.
Programmatic Signer’s architecture links the nonce advance and application changes, rolling them back together if execution fails. Vector documents a similar capability, ensuring that a failed submission doesn’t necessarily invalidate the approval. This retryability provides significant operational advantages, especially for complex institutional transactions that might encounter transient network conditions or application-level issues.
However, this persistence comes with caveats. Vector explicitly warns that a relayer could potentially withhold a transaction until favorable conditions arise or that a signature exposed by a failed attempt could be re-executed later. To mitigate this, signed instructions can include a timeout. Revocation requires a separately authorized nonce advance, ensuring that a deadline rejection doesn’t inadvertently consume the nonce if changes are rolled back.
Navigating Application Compatibility and Institutional Concerns
The Solana Foundation’s primary rationale for this architectural shift is to simplify validator handling. Durable nonces historically imposed special replay-prevention rules, complicated asynchronous execution, and made filtering invalid transactions more challenging. By migrating approval and replay state into ordinary programs, validators can process transactions more efficiently, treating them like standard blockhash-based actions.
However, this transition introduces new complexities for decentralized applications (dApps). Applications will now receive approved actions via cross-program invocation (CPI), where one program calls another. This mechanism can clash with existing dApp rules that expect actions to originate directly as top-level instructions. Checks designed for top-level interactions might also miss nested actions within the new signer program.
Institutional concerns on CPI
The compatibility of existing applications with CPI is a significant hurdle. More available call depth doesn’t automatically solve a rule that rejects the call’s position or cannot properly inspect nested instructions. The Solana Foundation acknowledges this, suggesting that applications might need to support known signer programs or offer alternative execution paths.
This means cryptographic validity of an offline approval is distinct from whether an application will actually accept a PDA’s signature.
Discussions among institutional players have highlighted these concerns. In a March 4 discussion, Michael from Fireblocks, a major digital asset custody provider, expressed support for nonce deprecation. However, he raised objections regarding the migration challenges, contract dependence, and DeFi compatibility burdens associated with the proposed CPI Passthrough. He advocated for alternatives like transaction envelopes or Sudo.
Addressing the Fireblocks perspective
The need for precise account-level assessments is evident, as illustrated by Token-2022’s CPI Guard. When this guard is enabled, CPI transfers and burns require delegate authority, while CPI-based approvals are prohibited. These specific rules demonstrate that a blanket ban on all PDA actions is not always the answer, but rather a nuanced approach to permissions and custody policies.
Another participant in the March 4 discussion, Grant from Unit 410, suggested that a small, auditable signer program could make authority migration acceptable. He explicitly rejected workarounds involving temporary asset transfers to hot signers, even for atomic operations, because funds must remain associated with cold storage in its non-custodial model. These insights underscore the rigorous requirements from institutional users.
Path to Mainnet and Broader Adoption
While the proposal offers significant advantages for Solana’s long-term scalability and security, the path to full implementation remains a work in progress. The Solana Foundation has emphasized that the roughly six-month migration window is contingent upon a suitable replacement being fully ready, rigorously audited, and live on the mainnet. This highlights a cautious and thorough approach to a critical infrastructure upgrade.
The adoption timeline will largely depend on the maturity and robustness of the chosen solution. Exchanges, custodians, and treasury operators require high assurance before committing to a new signing architecture, especially one that fundamentally alters asset control and transaction flows. The readiness of developer tools and application support will also play a pivotal role in accelerating migration.
Audits and readiness of proposed solutions
Anza’s Programmatic Signer, for instance, has been deployed on devnet, with audits currently underway. Its documentation indicates that remediation is required before a v1 release and eventual mainnet deployment. Critical features like simulation and relay submission are still marked as “coming soon,” alongside several unfinished migration operations in its guide.
Information on Blueshift’s Vector, while providing implementation code and program IDs, does not publicly state its audit or mainnet deployment status. This disparity in readiness underscores that both solutions still have significant development and validation milestones to meet. Full operational migration will demand an audited mainnet replacement that includes usable tools and application paths that uphold each operator’s crucial approval controls.
The Future of Solana’s Transaction Security
The existing durable nonce injection, as described by Fireblocks’ protocol onboarding kit for certain WalletConnect integrations like Jupiter and Kamino, currently operates with a default 15-minute validity window. Any new replacement must seamlessly accommodate such established approval workflows, ensuring minimal disruption to current institutional operations. This is crucial for Solana’s continued growth in the institutional space, alongside initiatives like tokenized stock offerings.
The ongoing development and careful consideration of institutional feedback signal Solana’s commitment to a more secure and efficient transaction environment. As the network matures, these foundational changes in how transactions are approved and executed will further solidify Solana’s position as a robust blockchain platform for diverse enterprise applications.
The migration represents not just a technical upgrade, but a strategic move towards a more resilient and institution-friendly ecosystem.