Signatures come first
A serialized transaction begins with a compact array of signatures — one entry per required signer. The message header declares how many signatures are required. If you submit a transaction with too few signatures, it is rejected before execution.
In explorers, you typically see signatures displayed as base58 strings at the top of the transaction detail page. The first signer is often the fee payer.
The message header
After signatures comes the message. The header holds three counts: required signatures, readonly-signed accounts, and readonly-unsigned accounts. These counts tell validators how to interpret the account meta flags that follow.
Account keys and metas
Every account touched by any instruction in the transaction must appear in the account keys list. The account meta byte for each key specifies signer status and writability. Order matters — programs expect accounts at specific indices.
When you add a second instruction, compare the account list before and after. Shared accounts appear once; new accounts append to the list. This is a common source of "AccountNotEnoughKeys" errors.
Recent blockhash
The message includes a recent blockhash tying the transaction to a narrow time window. Wallets refresh this value before submission. Stale blockhashes produce immediate rejection without program execution.
Instructions array
Each instruction names a program ID, lists account indices, and carries instruction data. Instructions execute sequentially. If instruction two fails, instruction one has already committed its state changes unless the whole transaction is atomic (which it is — all succeed or all fail).
Putting it together in an explorer
Open any confirmed transaction and identify: (1) signature count, (2) fee payer, (3) instruction list with program IDs, (4) inner instructions if present. Cross-reference unfamiliar terms in our glossary.
Want a live walkthrough? Our Transaction Anatomy Workshop traces three real examples with an instructor.