Reading account keys before the instruction data

The header tells you the shape of the list

A Solana message begins with three counts: required signatures, read-only signed accounts, and read-only unsigned accounts. Those counts slice the account-key array into signers and non-signers, and then into writable and read-only. We copy the three counts onto the top of the page before anyone is allowed to say what the transaction “does.”

Writable means the instruction is allowed to change that account’s data or lamports. Read-only means it should not. A failure that names a privilege or an owner often traces back to a flag someone assumed instead of counted.

Owner is not the same as signer

Each account on the chain has an owner program. A token account is owned by the token program. A wallet that signs is typically owned by the system program. In conversation both get called “the owner,” and the map falls apart. On paper we use “owner program” for the program and “authority” or “signer” for the key that approved the instruction.

A token transfer makes this concrete. The token account holds the balance. The mint defines the token. The authority signs. The fee payer may be none of those. Four keys, four jobs. The account map sitting exists because this sentence is easy to nod at and hard to keep straight once the list passes eight accounts.

Versioned transactions append loaded keys

A v0 message can keep some addresses in an address lookup table. The static keys are in the message. The loaded keys arrive with the transaction meta, in the order they were loaded, and they still occupy indexes that instructions point at. If you read only the static list, later instructions appear to cite accounts that are not on the page.

In the library folder, sample v0 transactions are clipped with the lookup table printed on a second sheet. We do not treat that sheet as optional.

If this is the field you want marked on your own signature, reserve a signature walkthrough or book a reading hour and name the guide.