Shelf guide · 2 March 2026
What a Solana transaction is asking for
We teach a transaction as a short stack of requests, plus proof that the right people agreed, plus a timestamp the network will still accept.
A transaction is not a coin flying from one pocket to another. That picture is too small, and it makes every other instruction look like a special case. At the library we treat a transaction as a signed list of instructions that the network will try to perform together.
The instruction card
Each instruction names three things. It names a program, the account that holds the code to run. It names the accounts that program is allowed to read or rewrite for this request. It carries a short data field that tells the program which action to take. A transfer of SOL is one instruction, sent to the system program. A more complicated transaction is several such cards in a fixed order.
Order is part of the meaning. We show this with blank envelopes in a row. Swap two envelopes and the second program may be asked to read an account the first program has not created yet. The network does not improvise the missing step. The transaction fails.
Who signs, and what the fee is for
A signature is an authorization from a key that the instruction requires. It is not a handwritten name and it is not a photograph of a passport. If a required signer is absent, nothing in the list runs. Learners meet this on evening three, with a sample that is correct in every field except one missing signature. Watching the whole list fail is more memorable than a definition.
The network charges a base fee per signature. In class we use the figure of 5000 lamports per signature as the working number for that base fee, and we say out loud that a priority fee is a later conversation. The first series does not tune fees. It only shows that a signature is not free, and that the fee is denominated in lamports, which is why evening one exists.
The blockhash, and the minute it lives
A transaction also carries a recent blockhash, a fingerprint of a recent point in the ledger. The network accepts that fingerprint only for a short window, on the order of a minute. This stops an old, already-seen transaction from being submitted again and again. It is also why a sample we print for class cannot be broadcast later as if it were still alive. The sample is for reading. Its blockhash is already a fossil by the time you fold the paper.
Put together, the rule we write on the board is short. Either every instruction in the list succeeds, or none of the changes are kept. That all-or-nothing behaviour is what people mean when they call a transaction atomic. You do not need the physics word. You need the habit of reading the whole list before you ask who must sign it.