Base interfaces & data structures by grod220 · Pull Request #1 · solana-program/nonce

grod220 · 2026-04-12T19:34:44Z

This PR adds base interfaces for the program: instructions, state, message schema, and PDA types.

Overall objective

Write a program that can serve as a functional replacement for the durable nonce usecase:

Approve something offline
Submit it later from a hot environment
Prevent replay
Support cold-signing and threshold-multisig workflows

The difference is that durable nonces do this via special runtime functionality (that folks are interested in removing), while this program does it through a promoting a PDA to signer on a pre-signed tx message.

Inspiration

Trent's durable nonce replacement proposal: solana-foundation/solana-improvement-documents#456

& Jon's idea to take a pre-signed-tx and promote the PDA to a signer on that tx.

High-level design

DurableSignerAccount: stores nonce Hash and an authority
DurableSignerPda: the PDA the program signs as during CPI
Submit instruction data: a serialized transaction payload

The intended flow is:

Derive DurableSignerAccount from the authority and DurableSignerPda from the DurableSignerAccount.
Initialize the account with the authority as a required signer.
Build a wrapped transaction-v1 message whose lifetime specifier is state.nonce.
Have every required wrapped signer authorize the canonical message bytes offline.
A hot wallet submits Submit with that wrapped transaction as instruction data.
Program then:
a. Verifies the stored authority signed the wrapped message
b. Checks message.lifetime_specifier == state.nonce
c. Executes each wrapped instruction by CPI, promoting DurableSignerPda to signer wherever referenced
d. Advances the nonce as sha256(tag ‖ state_pda ‖ old_nonce ‖ slot_hashes[0] ‖ sha256(message_bytes)).

Divergences from original proposal

This follows the spirit of Trent's original proposal, but there are a few divergences:

Does not use Vault naming as I felt it had too much overlap with the idea of custody and the defi vault concept.
Nonce is a 32-byte Hash advanced via a sha256 derivation and not a counter.
Signer seeds are not passed in the payload. The program derives one canonical authority PDA from the authority policy.

What's next

Add Codama support
Generate clients
Program implementation
Tests
CLI helpers
Benchmarking

t-nelson

good start!

joncinque

This is definitely on the right track!

We were talking about this offline, and I mentioned that a good use-case to target is minting SPL tokens, where the mint authority is a multisig, which I think is essentially Trent's sign(sign(sign(... example.

As another consideration, if people want to use tools like Ledgers as their offline signer, I don't think the current format will be accepted. We might need these to look like a Solana transaction instead, so that existing tools Just Work ™️

t-nelson · 2026-04-21T14:17:01Z

what's status here? foundation wants an example to float to current durable nonce consumers

grod220 · 2026-04-21T14:47:04Z

@t-nelson sorry for the delay on iterating on this. Talked offline to Jon a bit about a simpler design today. Expect an update soon.

grod220 · 2026-04-22T01:15:50Z

inspired by jon

This next iteration is an alternative design that simplifies the program a good deal. New flow:

Consumer uses a standard signed solana_transaction::Transaction as the Submit payload.
Nonce program validates: message.account_keys[0] == authority stored in PDA state && message.recent_blockhash == nonce in PDA state.
Nonce program executes message.instructions by CPI, promoting NonceAuthorityPda to is_signer=true

It's no longer necessary to define a custom inner message format. This makes it friendlier to work with existing infra that expects signatures on the legacy transaction format.

Also removed embedded deadline/multisig support. Delegates that responsibility to external CPIs.

t-nelson

making the payload (at least optionally) a transaction i think will ease some migration concerns. we'll need to think about how to handle some of the current features that are specified in transaction payloads, but require runtime support, which will not be available for these. similarly, how the message header will be handled

grod220 · 2026-04-30T22:28:55Z

@joncinque @t-nelson re-review on the updated API when you have a chance 🙏

t-nelson · 2026-05-01T19:45:17Z

+    pub nonce: Hash,
+    /// Address allowed to consume this nonce and advance its value. `Submit` verifies that this
+    /// address signed the wrapped transaction message.
+    pub authority: Address,


since we're enforcing a 1:1 mapping of authority to pda, this field is superfluous since it must be passed in the tx, right?

API update here: #1 (comment)

Think parallelism is a legitimate usecase requested from foundation.

p sure it's the nonce hash that prevents "parallelism", not the authority

we need to tell these people that we're shipping an mvp replacement here, not taking feature requests

An authority makes sense if we want to cover the existing use-case, where you have a nonce authority that must sign to advance the nonce, and then a bunch of other signers who are signers on the transaction.

A single authority can manage multiple nonce accounts for different offline signers. As a custodian, I might use the same authority for many different clients. When they want to move funds, they sign with one of my many accounts

sure but we already have the authorities and the submit ix accounts list, as presently defined, only supports a single vault account. we can encode its authority in the ordering, like we do with the fee payer on outer tx, then assert it by virtue of the associated pda being passed. this could be trivially extended to multiple vault accounts should we choose with a vault count in the ix data

So I'm sure we're on the same page, there's two kinds of accounts: the PDA being promoted, and the account storing the hash and authority. For clarity, let's call the PDA the "vault" since it actually owns assets, and the other account the "durable signer".

In that sense, transactions must have at least one durable signer, and need to support having multiple vaults. Otherwise this program won't support existing use-cases, where multiple keypairs perform offline signing.

t-nelson · 2026-05-01T19:48:45Z

-homepage = {workspace = true}
-license = {workspace = true}
-edition = {workspace = true}
+description = "Interface for the SPL Nonce program"


i'm thinking maybe we should just drop the "nonce" terminology altogether. any "programmatic signer/authority" can be used to decouple asset authority from signatures that must cover the recent blockhash

Interesting. Would spl-program-signer or spl-pda-authority or spl-authority-proxy be more accurate?

spl-ed25519-signer?

@joncinque join the bikeshed session!

I've been summoned! I really like including ed25519. On the other hand, this is still meant to cover single-use durable signatures, so how about spl-ed25519-durable-signer?

Updated terms!

there really isn't anything "durable" about this thing tho. that qualifier was added to the original feature as a call out to its extending the ttl of an otherwise short-lived nonce value. here we're simply never signing a nonce with a lifetime at all. this is so much more powerful and shouldn't be burdened by historical artifacts. the technology has advanced to the point as to make the old ways irrelevant. let them die

wherever we land, we should also rename the repo before it gets much content

I'm not sure I understand -- "durable" means "long-lasting", and this program provides a long-lasting way to sign transactions. What are other powers that you want to highlight with the name?

Someone could make a different version of this program that requires signing the same blockhash as the outer transaction, which could be called ed25519-blockhash-signer. In this case, would ed25519-hash-signer be better? Or if you feel really strongly about spl-ed25519-signer, I can get behind it

joncinque

This is on the right path for me, I think implementation can get started very soon!

joncinque · 2026-05-05T20:10:10Z

+    pub nonce: Hash,
+    /// Address allowed to consume this nonce and advance its value. `Submit` verifies that this
+    /// address signed the wrapped transaction message.
+    pub authority: Address,


An authority makes sense if we want to cover the existing use-case, where you have a nonce authority that must sign to advance the nonce, and then a bunch of other signers who are signers on the transaction.

A single authority can manage multiple nonce accounts for different offline signers. As a custodian, I might use the same authority for many different clients. When they want to move funds, they sign with one of my many accounts

joncinque · 2026-05-05T20:14:35Z

+    /// Runs only as an inner instruction of a wrapped transaction submitted through `Submit`
+    /// because nothing outside this program can sign for `NonceAuthorityPda`.


This is clever! And makes sense, it's a great show of how this would work

Yeah, I found myself thinking through auth for this message and found the duplication annoying. Think this method addresses that!

joncinque · 2026-05-05T20:26:57Z

+    /// 2. Reads the authority stored in the nonce state account.
+    /// 3. Checks the passed nonce state account's authority signed the wrapped message.
+    /// 4. Checks the wrapped message's lifetime / recent blockhash field equals `state.nonce`.
+    /// 5. Verifies the outer transaction's only top-level instruction is `Submit`.


I wasn't sure about this restriction, but we can always relax it in the future if there are legitimate use-cases hampered by it

i think the only real concern is that it makes v1 transactions a prerequisite for consumers that require compute budget instructions

The program could potentially just skip compute budget instructions, no?

joncinque · 2026-05-05T20:33:58Z

+    /// - Remaining: all accounts referenced by the wrapped message, in order, with `is_signer`
+    ///   and `is_writable` flags matching the wrapped message.


We'll see how this shakes out in the implementation, but it isn't possible for non-pda signers to appear in the original message, unless we expect them to sign the inner and outer transactions.

True. I suppose we could do something where a missing inner signature can be satisfied by outer transaction signer. That sort of would be a way to designate an intended hot wallet broadcaster. Hmm, may be best to come back to this during the implementation PR. Going to drop the is_signer language here for now.

joncinque · 2026-05-06T10:28:38Z

This looks good to go from my side to start implementation, but please get @t-nelson 's approval

Base interfaces & data structures

5edd18c

grod220 requested review from joncinque and t-nelson April 12, 2026 19:38

t-nelson reviewed Apr 14, 2026

View reviewed changes

joncinque reviewed Apr 16, 2026

View reviewed changes

Comment thread interface/src/state.rs Outdated

Comment thread interface/src/state.rs Outdated

alt design: promote PDA to signer

25d24d1

grod220 requested review from joncinque and t-nelson April 22, 2026 01:27

t-nelson reviewed Apr 23, 2026

View reviewed changes

Comment thread interface/src/instruction.rs Outdated

Comment thread interface/src/instruction.rs Outdated

Comment thread interface/src/instruction.rs Outdated

Comment thread interface/src/instruction.rs Outdated

grod220 added 3 commits April 24, 2026 20:19

update to v1 tx type

326065d

one pda per authority

b2a1301

require signer on Initialize

3ab3517

grod220 force-pushed the base-ixs branch from 76204b8 to 3ab3517 Compare April 25, 2026 04:37

grod220 requested a review from t-nelson April 25, 2026 04:46

API update

1c0e2d0

t-nelson reviewed May 5, 2026

View reviewed changes

joncinque reviewed May 5, 2026

View reviewed changes

grod220 added 3 commits May 5, 2026 17:36

change to spl-ed25519-durable-signer terms

f46afdb

update Submit code docs

40b9ffa

addr update

75dd928

grod220 requested review from joncinque and t-nelson May 5, 2026 23:05

		/// Runs only as an inner instruction of a wrapped transaction submitted through `Submit`
		/// because nothing outside this program can sign for `NonceAuthorityPda`.

		/// - Remaining: all accounts referenced by the wrapped message, in order, with `is_signer`
		/// and `is_writable` flags matching the wrapped message.

Conversation

grod220 commented Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overall objective

Inspiration

High-level design

Divergences from original proposal

What's next

Uh oh!

t-nelson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

t-nelson commented Apr 21, 2026

Uh oh!

grod220 commented Apr 21, 2026

Uh oh!

grod220 commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

t-nelson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

grod220 commented Apr 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

grod220 commented Apr 12, 2026 •

edited

Loading

grod220 commented Apr 22, 2026 •

edited

Loading