Solana Transaction Authorization Today

Anatomy of a transaction

A Solana transaction is a compact array of signatures followed by a message. The message contains a header, the list of account addresses the transaction touches, a recent blockhash and the instructions to execute. Each signature is a 64-byte Ed25519 signature over the serialised message, produced by the private key corresponding to one of the listed account addresses.

The first listed signer pays the fee. Validators verify every signature against the corresponding public key before executing the instructions. If any signature fails, the transaction is rejected.

Addresses are public keys

A regular Solana account address is a 32-byte Ed25519 public key, usually shown in base58. There is no hashing step between the key and the address. This keeps verification simple and means every funded account's public key is visible on the ledger.

The size budget

Transactions are limited to 1,232 bytes, a figure derived from the IPv6 minimum MTU minus headers. Signatures, account addresses and instruction data all share that budget. A transaction with two signers already spends 128 bytes on signatures and 64 bytes on their addresses before any instruction data.

This budget is the single most important constraint when considering post-quantum signatures on Solana. ML-DSA-44's 2,420-byte signature does not fit; SLH-DSA signatures are far larger still.

Program-controlled accounts

Not every account is controlled by a private key. Program Derived Addresses (PDAs) are addresses that deliberately have no corresponding private key; only the program that derived them can sign on their behalf, by invoking cross-program instructions. Programs can therefore implement their own authorisation rules over the assets they hold.

This is the mechanism that makes application-level experiments possible. A program could, in principle, verify a post-quantum signature passed in instruction data and release funds from a PDA if it is valid. The transaction that carries that instruction still needs an Ed25519 signature from a fee payer, so the base layer's authorisation model is unchanged.

Native signature verification programs

Solana ships native programs that verify Ed25519 and secp256k1 signatures within a transaction, which lets programs check signatures made with keys other than the transaction signers. There is no equivalent native program for post-quantum schemes at the time of review; verifying one would have to be implemented in a program's own code within compute and size limits.

What migration would require

Any base-layer change would need, at minimum: a transaction format that accommodates larger signatures or a different packaging, validator-side verification for the new scheme with appropriate fee accounting, a path for existing Ed25519 accounts to designate a new key type, and wallet and hardware support. Each is a protocol-level decision that application developers cannot make unilaterally.

The Lattice playground demonstrates algorithms at the application level only, and states this on every result.