Base interfaces & data structures

[grod220]

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 signed program message.

Instead of signing a full transaction offline, authority members sign a structured SignedMessage that commits to the exact action being approved. It doesn't require any special features and can work today. Even further, it can enable additional features like signature expiry.

Inspiration

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

High-level design

• NonceState: which stores the current nonce plus the AuthorityPolicy
• NonceStatePda: the PDA that stores state
• NonceAuthorityPda: the PDA the program signs as during CPI
• InstructionData / SignedMessage: the offline-signed authorization format
• SignedAction: Supported actions that can be executed by the program

The intended flow is:

1. Derive and initialize the canonical nonce state PDA for an authority policy
2. Build and serialize a SignedMessage
3. Have authority members sign those exact bytes offline
4. Submit the signed message on-chain later via Submit
5. Program then:
   1. Verifies signatures, nonce, and deadline
   2. Performs the approved action
   3. Increments the nonce

Divergences from original proposal

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

• The signed message commits to the full CPI account table, so account substitution is not possible
• The signed message commits to per-account signer and writable privileges
• The signed header includes an optional deadline
• Authority is modeled as an AuthorityPolicy with threshold plus ordered members, rather than a single authority key
• 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