Durable Nonces: Two-Device Signing on Solana
SSP is a 2-of-2 wallet. Every transaction needs two signatures: one from the browser-extension Wallet on your computer, and one from SSP Key on your phone. That design is the whole point — a thief who steals one device still cannot move your funds. But it introduces a very human problem. The computer builds and signs a transaction in a fraction of a second. The phone might not co-sign for another two or three minutes, because a person has to pick up the phone, look at the request, and tap approve.
On Solana, that gap is a problem. This article explains why, and how SSP solves it without storing anything fragile.
The blockhash that expires
Every normal Solana transaction carries a piece of data called a recent blockhash. It is a fingerprint of a recent block on the chain, and it does two jobs at once. It proves the transaction was created recently, and it stops the same signed transaction from being replayed forever.
The catch is in the word recent. A blockhash is only valid for roughly 150 blocks. On Solana, blocks come fast, so 150 blocks is only about 60 to 90 seconds. After that window, the network rejects the transaction outright — not because anything is wrong with the signatures, but because the blockhash is stale.
Now put the SSP signing flow against that clock. The Wallet builds the transaction, pins a fresh blockhash, and signs. The user is then notified on their phone. If they answer within 90 seconds, fine. If they are in a meeting, or the phone is in another room, or they simply want to read the transaction carefully, the blockhash quietly dies. The Wallet's signature is still cryptographically valid, but the transaction it was attached to is now worthless. The whole thing has to be rebuilt and re-signed from scratch.
For a single-signer wallet that signs and broadcasts in one breath, the 90-second window is generous. For a 2-of-2 wallet where a human stands between the two signatures, it is a race the user keeps losing.
What a durable nonce is
Solana has a built-in answer to this, and it predates SSP: the durable nonce. The idea is to replace the expiring blockhash with a value that does not expire.
A durable nonce lives in its own small account on the chain — a nonce account. This account is system-owned, holds just 80 bytes of data, and one of those pieces of data is the nonce value itself: a long-lived stand-in for a blockhash. A transaction can be built to use the nonce account's value instead of a recent blockhash. Because that value does not age out, the transaction stays valid for as long as it takes — minutes, hours, days.
Nothing is free, though, and a nonce needs a guard against replay. That guard is a rule: any transaction that uses a durable nonce must carry a specific instruction, nonceAdvance, as its very first instruction. When the transaction finally lands, nonceAdvance consumes the current nonce value and rotates the account to a new one. The nonce is single-use. The transaction you signed on Monday can wait until Wednesday, but once it executes, that exact nonce can never authorize another transaction. If you want to read Solana's own description of the mechanism, the durable transaction nonces documentation is the primary source.
So a durable nonce buys time without buying a replay risk. That is exactly the property a two-device wallet needs.
SSP's twist: a nonce account you never have to store
A durable nonce account is still an account, and on Solana every account has an address. The naive approach is to create a nonce account at some random address, then carefully remember that address forever — write it into the wallet's local storage, back it up, hope it survives a device reset. That is one more fragile thing to lose.
SSP refuses to store it. Instead, the SSP Solana multisig program includes an instruction called provision_nonce, and it creates the nonce account at a derived address. The address comes from a deterministic recipe: it is computed from the multisig account itself, the fixed text label "nonce", and Solana's System Program. Same multisig in, same nonce address out — every single time.
This matters because of what the rest of this series has already established. SSP's Solana multisig derives the multisig address from the member set, and derives the vault address from the multisig. (If those derivations are new to you, the self-initiating Solana multisig article walks through them.) The nonce account now joins the same family: it too is a pure derivation. Any SSP device — your computer, your phone, a freshly reinstalled wallet — can recompute the nonce account's address from scratch. There is no secret address to lose, because there is no stored address at all.
A few practical notes follow from the design. provision_nonce is permissionless: anyone can pay the small rent (about 0.00144 SOL) to bring the nonce account into existence, and whoever pays becomes its initial authority — in practice the SSP relay's paymaster. That authority can later be reassigned without the account's address ever changing, so the address you derive today stays correct even if the operational key behind it rotates. The nonce account's location is anchored to your multisig, not to whoever happened to fund it.
The calm signing flow
Put the pieces together and the race disappears. The Wallet builds a transaction that uses the derived nonce account instead of a recent blockhash, places nonceAdvance as the first instruction, and signs. A push notification goes to the phone. The user approves whenever they are ready — there is no clock ticking against them. SSP Key adds the second signature, and the fully-signed transaction is broadcast. Because it was built on a durable nonce, it is still valid, and nonceAdvance rotates the nonce so the transaction cannot be replayed.
There is one more constraint worth naming. Solana caps a single transaction at 1232 bytes. A multisig transaction has to fit the member list and the spending instructions inside that limit, which is why SSP uses Solana's compact versioned transaction format and passes data as tightly as possible. The durable nonce does not change the size budget; it only changes the time budget.
Derive everything, store nothing
This is the thread that runs through the whole Solana Multisig, Done the SSP Way series. The multisig address, the vault that holds your funds, and now the nonce account that gives two devices time to agree — none of them is a value SSP has to save and protect. Each is recomputed on demand from inputs the wallet already knows. There is less to back up, less to leak, and less to go wrong on a device reset. Multisig designs that lean on this idea, like SSP's single-signer multisig approach, tend to be the ones with the fewest moving parts to break.
A closing note in the same spirit of honesty as the rest of the series: SSP's Solana multisig program is currently deployed on devnet only, and is pending an external security audit before any mainnet release. The design described here — including provision_nonce and its derived nonce account — is real and readable in the open-source program, but it is not yet production infrastructure. If you are new to SSP's two-device model itself, the what is 2-of-2 multisig primer is the place to start.
The durable nonce is a small, old piece of Solana plumbing. SSP's contribution is to make its address one more thing you never have to remember.
