Understanding Solana Transactions

Most beginners think a transaction is just “the thing that sends SOL.”

That description is too shallow.

A Solana transaction is a signed message that tells the network which instruction to run, which accounts are involved, and who has approved the action.

That is the mental model you need for everything that comes later.

If you understand transactions, program calls stop feeling magical.

What You Are Learning

By the end of this lesson, you will be able to:

• explain what a Solana transaction actually is
• identify the main pieces inside a transaction
• understand why some accounts sign and others do not
• explain what a recent blockhash does
• describe how a transaction goes from your machine to the network

Start with One Real Transaction

Use the transfer from the last lesson as the anchor example:

solana transfer wallet2.json 0.01 --from wallet1.json --allow-unfunded-recipient

From the terminal, that looks like one line.

Inside the network, it is more structured.

This command causes the CLI to build a transaction that roughly means:

Run a system transfer instruction.
Move 0.01 SOL from wallet1 to wallet2.
Use wallet1 as the signer and fee payer.
Attach a recent blockhash so the network treats the message as fresh.

That is already enough to see the important shift in thinking:

A transaction is not the same thing as a command.

The command is what you type. The transaction is the signed message the CLI sends to Solana.

The Four Pieces Inside a Transaction

For Week 1, you can think of a transaction as having four important pieces:

1. Instruction
2. Accounts
3. Signatures
4. Recent blockhash

Here is what each one means.

1. Instruction

The instruction is the actual action you want the network to execute.

In the example above, the instruction is a system transfer.

Later in the course, instructions might also mean:

• create an account
• mint a token
• call an Anchor program
• update some on-chain state

A transaction can contain one instruction or several.

2. Accounts

Instructions do not run in a vacuum. They need accounts.

For a simple SOL transfer, the important accounts are:

• the sender account
• the recipient account
• the System Program

The transaction has to name those accounts explicitly so the runtime knows what can be read, written, or executed.

3. Signatures

A signature proves that the right private key approved the transaction.

In the SOL transfer example, wallet1 must sign because it is authorizing funds to leave that account.

This is where beginners often get tripped up:

• an account can be involved in a transaction without signing
• an account can be writable without being a signer

For example, wallet2 receives funds, but it does not need to sign just to receive them.

That distinction matters later when you start passing multiple accounts into programs.

4. Recent Blockhash

A transaction also carries a recent blockhash.

Do not think of it as a timestamp in the normal wall-clock sense. Think of it as a freshness marker.

It tells the network, “this transaction was built recently enough to still be valid.”

That helps prevent old signed transactions from being replayed later.

Most of the time, the CLI or SDK fetches and inserts the blockhash for you. You still need to know why it is there.

What the Transaction Is Really Saying

If we rewrite the earlier transfer in plain English, the transaction is roughly saying:

System Program,
please move value from wallet1 to wallet2.
wallet1 approves this action.
Here is a recent blockhash to prove this request is still fresh.

That is a much better mental model than “I ran a transfer command.”

The network is not reading your terminal command. It is validating and executing a structured, signed message.

How a Transaction Moves Through the Network

Now that you know what is inside the message, here is the lifecycle.

Why Signers Matter So Much

Signers are the permission layer of Solana transactions.

If the wrong account signs, or a required signer is missing, the instruction should fail.

That is how Solana prevents random clients from spending someone else’s funds or mutating protected state.

A useful Week 1 rule is:

• if an account is paying, authorizing, or proving ownership, expect a signature to matter
• if an account is only being referenced or receiving value, it may not need to sign

This rule is not the full runtime model, but it will keep your intuition pointed in the right direction.

Why the Recent Blockhash Matters

Without a freshness check, an old signed transaction could be reused later.

That would be dangerous.

The recent blockhash reduces that risk by making transactions expire after they are no longer recent enough.

This has a practical consequence for developers:

if you build a transaction and wait too long before sending it, the transaction can expire and fail even if the signatures are correct.

That is why transaction-building libraries fetch blockhashes close to send time.

One More Useful Detail: Instructions Are Atomic

A transaction can contain multiple instructions.

When that happens, they run as one atomic unit.

That means:

• either the whole transaction succeeds
• or the whole transaction fails

You do not get half a successful transaction.

That property becomes more important once you start creating accounts and then using them in the same transaction.

Common Mistakes

Summary

A Solana transaction is a signed message, not just a wallet action.

It carries:

• an instruction that says what should happen
• the accounts involved in that action
• signatures that authorize it
• a recent blockhash that proves the message is still fresh

That is why the transfer from the previous lesson worked the way it did.

The CLI built the message, wallet1 signed it, the network checked it, and validators applied the state change.

With that model in place, the next lessons on architecture and programs will make much more sense because you now know what is actually moving through the network when you interact with Solana.