InvestNot yet confirmed elsewhere1 publisher2 min readPublished
Solana's durable-nonce replacements can leave failed approvals executable later
Solana Foundation's plan to retire durable nonces gives a roughly six-month migration window, conditional on an audited mainnet replacement. Cold keys would keep approving while program-derived addresses control the affected accounts, CryptoSlate reported.
The Investor · Invest desk
Operators must migrate assets or permissions. Apps must accept actions from another program. Risk teams must approve the new signing path. A treasury's accounts and key permissions decide what changes. Programmatic Signer relayers can add instructions; Vector needs them set at signing.
- constraint Operators Must migrate the relevant assets or permissions, claim 17
- constraint Applications Must accept actions arriving through another program, claim 17
- decision Risk teams Must approve the new signing path, claim 17
- exposure Affected treasuries Account inventory and the permissions each key currently holds determine what must change, claim 15
- capability Programmatic Signer relayers Can choose the outer fee payer and blockhash and add instructions before or after the submission, claim 12
- constraint Vector cold-key signers Instructions surrounding approved actions must already be included when the cold key signs, claim 13
| Who | How | Kind | Claim |
|---|---|---|---|
| Operators | Must migrate the relevant assets or permissions | constraint | 17 |
| Applications | Must accept actions arriving through another program | constraint | 17 |
| Risk teams | Must approve the new signing path | decision | 17 |
| Affected treasuries | Account inventory and the permissions each key currently holds determine what must change | exposure | 15 |
| Programmatic Signer relayers | Can choose the outer fee payer and blockhash and add instructions before or after the submission | capability | 12 |
| Vector cold-key signers | Instructions surrounding approved actions must already be included when the cold key signs | constraint | 13 |
What happened
- Under Programmatic Signer, the cold key signs an authorization message instead of the transaction, a relayer wraps it in a fresh-blockhash transaction, and the signer program executes with the derived address as signer.
- The migration guide describes moving native SOL, token balances and mint or freeze permissions to the derived address, and moving staker authority, withdraw authority or both on stake accounts.
- Durable nonces remain usable, and the Foundation has set no removal date or final choice between Anza's Programmatic Signer and Blueshift's Vector.
- The two designs treat native SOL differently: Programmatic Signer's derived account is System-owned, while Vector initializes a program-owned account that releases SOL through its own withdrawal or closing operation.
Why it matters
- cost Treasuries have to inventory their accounts and authorities: approving the new signing software is only part of the job, and the permissions each key holds today decide which accounts must be moved.
- exposure Any offline approval that failed to land is a candidate for later execution, so custodians need a list of outstanding approvals as well as a list of accounts.
- decision Operators must decide whether to start the handoffs before the Foundation picks a design, since the proposal has them finish while legacy durable nonces still work.
- constraint Applications must accept actions arriving through another program, so a custodian cannot finish the migration alone.
The cold key keeps its job, so the live question for a custodian is how much of the surrounding transaction its signature pins down. Programmatic Signer's message documentation, as CryptoSlate describes it, says the cold signatures bind the executor, the nonce account and the embedded execution message. A relayer cannot alter those bytes while keeping the signatures valid [11]. The relayer can still choose the outer fee payer and the blockhash, and can place extra instructions ahead of or behind the submission [12].
Vector's cold signature covers the top-level instruction buffer. That includes the data and accounts that hand approved actions on to other programs. The instructions around those actions must already be included when the cold key signs [13]. On those two descriptions Vector fixes more at signing time and leaves the relayer less room [19]. The comparison rests on CryptoSlate's summaries of the designs, not on the specifications.
Tighter binding does not settle the stale-approval problem, since CryptoSlate says both designs can leave a failed approval executable later [14]. We think the two cases differ in size. A stale Programmatic Signer approval could land with a different fee payer and extra instructions around it. A stale Vector approval is bounded by the buffer the cold key committed to [20]. Either one is a signed instrument that still works after the attempt meant to use it has failed [14].
Timing adds pressure from the other side. On Oct. 9, Solana's 200ms slot upgrade hit its last mainnet stage [8]. With blocks coming faster, ordinary blockhash approvals get less wall-clock time, though expiry depends on block production and not on a guaranteed timer [9]. CryptoSlate says the nonce proposal concerns the architecture used to avoid that short approval window [10].
We think operators should inventory accounts and authorities now and hold off on writing approval policy around either design. The inventory is needed whichever one wins, and the policy depends on which one does. The counter-thesis is that nothing forces the pace: the six-month clock sits behind three gates [18], and any of them can slip. If the final design enforces a mandatory deadline on every authorization, the exposure is smaller than we say. The stale-approval problem would then reduce to an expiry setting.
What to watch
- Whether the Foundation picks Programmatic Signer or Vector, and whether the final design enforces a mandatory deadline on every authorization.
- Audit completion and mainnet go-live of a replacement, the gates in front of the roughly six-month migration window.
- Whether the Foundation sets a durable-nonce removal date, which none of the reporting shows so far.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption
- Insufficient
- Hype gap+8
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
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.
- [2]
The Solana Foundation's October deprecation plan points to onchain signer programs that verify an offline signature and execute its approved instructions, with a program-derived address controlling the affected accounts.
- [3]
The Foundation's roughly six-month migration window is conditional on a suitable replacement being ready, audited and live on mainnet.
- [4]
Under Programmatic Signer, the cold key signs an authorization message rather than the transaction sent to the network; a relayer places the approval in a fresh-blockhash transaction, and the signer program verifies it and executes the approved instructions with the key's derived address as signer.
- [5]
The migration guide describes moving native SOL into the derived address, transferring token balances into accounts it controls, and moving mint or freeze permissions to it; stake accounts can move the staker authority, withdraw authority or both.
- [6]
Durable nonces remain usable, and the Foundation has not set a removal date or made a final choice between Anza's Programmatic Signer and Blueshift's Vector.
- [7]
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.
- [8]
Solana's separate 200ms slot upgrade reached its final mainnet stage on Oct. 9.
- [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.
- [10]
The nonce proposal concerns the architecture used to avoid the short approval window.
- [11]
Programmatic Signer's message documentation says the cold signatures bind the executor, nonce account and embedded execution message, so a relayer cannot alter those authorized bytes while retaining valid signatures.
ReportedSupportedSource: CryptoSlate, citing Programmatic Signer's message documentationView cited source - [12]
Under Programmatic Signer a relayer can choose the outer fee payer and blockhash and add instructions before or after the submission.
- [13]
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.
- [14]
Both proposed designs can leave failed approvals executable later, making deadline enforcement and nonce revocation material custody controls.
- [15]
For an affected treasury, approving the new signing software is only part of the job; its account inventory and the permissions each key currently holds determine what must change.
- [16]
The Foundation proposes completing the asset and permission handoffs while legacy durable nonces still work.
- [17]
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.
- [18]
Three conditions (ready, audited, live on mainnet) must be met before the roughly six-month migration window applies.
- [19]
On CryptoSlate's descriptions, Vector requires surrounding instructions to be fixed when the cold key signs, while Programmatic Signer lets the relayer add instructions around the submission, so Vector leaves the relayer less room.
- [20]
A stale Programmatic Signer approval could land with a different fee payer and extra instructions around it, while a stale Vector approval is bounded by the instruction buffer the cold key committed to.
Sources
1 independent publisher whose own reporting we read for this story.
- cryptoslate.comSolana’s offline-signing proposal would keep approvals valid after failed transactions
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.