Inside a Solana transaction, byte by byte

A legacy transaction is a compact array of signatures followed by a message. The message has a three-byte header (how many signatures are required, and how many signed and unsigned accounts are read-only), the list of account keys, a recent blockhash, and the instructions. Here is a real one-signer transfer of lamports to yourself, the transaction the Lab's Devnet panel sends:

Version 0 transactions add address lookup tables, which replace 32-byte keys with one-byte indexes into an on-chain table. They shrink the account list. They do nothing for signatures.

Transactions travel as single UDP-sized packets, so the cap is the IPv6 minimum MTU of 1,280 bytes minus 40 bytes of IPv6 header and 8 bytes of UDP header. Every signature and every key spends from that budget. Swap the 64-byte signature above for ML-DSA-44's 2,420 bytes and carry its 1,312-byte public key, and the same transfer becomes about 3,800 bytes, more than three times the cap.

Raising the limit has been discussed in the Solana improvement process. At the time of writing the cap stands, and any post-quantum signer type would need it, or something equivalent, to change.

Signatures are checked in the leader's signature-verification stage, often on GPUs, before execution. Programs never see the signature bytes. They see an is_signer flag on each account, which the runtime only sets after verification succeeded.

For signatures over data other than the transaction itself, Solana has precompiles: native programs that verify Ed25519, secp256k1 and secp256r1 signatures passed in instruction data. A program can read the instructions sysvar to confirm that a precompile check ran in the same transaction. The secp256r1 precompile, added for passkeys, shows the network can add new curves. No post-quantum precompile exists today.

1. Transaction signers. The runtime accepts only Ed25519 signers. A post-quantum signer type is a protocol change: a new signature format, verification support in every validator, and room in the packet.

2. Addresses. A wallet address is its Ed25519 public key. A 1–2 KB post-quantum key cannot be an address, so a future design would likely use a hash of the key, with the key itself supplied when signing. Either way, moving to post-quantum keys means moving funds and authorities to new addresses.

3. Verification inside programs. A program can verify a post-quantum signature today, but the signature arrives as instruction data, and an ML-DSA signature does not fit in one transaction. It has to be written into an account over several transactions and verified afterwards, within compute limits. Hash-based one-time signatures fit better, because verifying them is mostly hashing, which is cheap on Solana.

4. Off-chain messages. Sign-in messages, oracle reports, bridge attestations and API authentication are not bound by the packet size. These can move to ML-DSA or a dual signature first.

A normal transaction expires with its blockhash after roughly a minute. A transaction built on a durable nonce stays valid until the nonce advances. Anything pre-signed and stored that way is a long exposure window.

The keys that matter most are the ones that hold authority for years: program upgrade authorities, mint and freeze authorities, multisig members, stake and withdraw authorities, and validator identities. List them first; the readiness check asks about each.

• Keep an inventory of every authority key, what it controls and who holds it.
• Put high-value authorities behind a multisig, and revoke upgrade authorities that no longer need to exist.
• Design programs so that authorities can be reassigned, so you can move them to a post-quantum-capable vault later.
• For cold storage, consider hash-based vault programs, and get them independently reviewed first.
• Follow the Solana improvement documents for proposals on transaction size and new signature types.