Over the past few days, I've been learning Solana transactions by doing what every developer eventually does: building things, breaking them, and trying to understand what happens under the hood.
At first, I thought a transaction was just a blockchain version of an API request.
- Create it.
- Send it.
- Wait for a response.
- Done.
But Solana transactions are much more than that.
A transaction is a cryptographically signed package containing instructions, accounts, metadata, and execution rules that validators process atomically.
To better understand the process, I built a small script that transfers SOL on Devnet while exposing every major component of the transaction before it reaches the network.
Let's follow that transaction from creation to finalization.
The Transaction Lifecycle
Before writing any code, it helps to visualize what actually happens.
Create Transaction
│
▼
Add Instructions
│
▼
Attach Recent Blockhash
│
▼
Sign Transaction
│
▼
Send To Network
│
▼
Processed
│
▼
Confirmed
│
▼
Finalized
Every transaction on Solana follows a similar path.
The transfer itself is just one instruction inside a larger structure.
Visit the complete script
✅ anatomy of a transaction script
Step 1: Loading the Signer
The first thing my script does is load the wallet generated by Solana CLI.
This signer is more than just an address.
It contains the cryptographic key pair required to authorize changes on-chain.
Without a valid signature, validators will reject the transaction immediately.
When the script starts, it prints information about the wallet and current balance:
Wallet: 8xY...
Balance: 4.82 SOL
This account will also become the fee payer for the transaction.
Step 2: Fetching a Recent Blockhash
Before a transaction can be submitted, it needs a recent blockhash.
A common misconception among new developers is that transactions remain valid forever.
They don't.
The recent blockhash acts as an expiration mechanism.
If too much time passes before the transaction reaches the network, validators will reject it.
This design helps prevent replay attacks and ensures transactions are processed within a limited time window.
My script prints:
Blockhash: 7P7...
Last Valid Block Height: 412345678
This information defines the lifetime of the transaction.
Step 3: Creating an Instruction
Transactions don't perform actions by themselves.
Instructions define what should happen.
For this example, the instruction is a simple SOL transfer.
This tells Solana's System Program:
> Transfer a specific amount of SOL from one account to another.
The script outputs:
Type: System Program Transfer
From: 8xY...
To: FdQ...
Amount: 0.01 SOL
Although this example contains a single instruction, a transaction may include multiple instructions that execute together.
Step 4: Building the Transaction
Now we assemble all the pieces.
This is where the transaction anatomy becomes visible.
The transaction now contains:
- A fee payer
- A recent blockhash
- One instruction
- Required account metadata
At this point the transaction is fully constructed but still cannot be executed.
Why?
Because it hasn't been signed.
Step 5: Signing the Transaction
Signing proves authorization.
The resulting signature becomes the unique identifier for the transaction.
Output:
Signature:
5q8mD7...
One important detail is that changing any part of the transaction after signing invalidates the signature.
Validators verify this before execution.
Step 6: Broadcasting to the Network
Once signed, the transaction is serialized and sent.
At this stage the transaction leaves my machine and enters the validator network.
This is where many developers expect the process to be finished.
In reality, it's only beginning.
Step 7: Understanding Commitment Levels
One of the most interesting concepts I encountered while learning Solana was transaction commitment.
A transaction doesn't instantly become final.
Instead, it moves through several states.
Processed
✓ Processed
The transaction has been included in a block and executed.
However, the network has not yet fully agreed on its permanence.
Confirmed
✓ Confirmed
A supermajority of validators has voted on the block.
Confidence is significantly higher.
Finalized
✓ Finalized
The block is considered irreversible.
For applications that require maximum certainty, this is usually the status that matters most.
My script waits for all three stages and prints each one as it occurs.
Watching the transaction progress through these levels helped me understand that blockchain state isn't updated in a single instant.
Consensus is a process.
Viewing the Transaction On-Chain
After finalization, the script prints a Solana Explorer URL.
https://explorer.solana.com/tx/?cluster=devnet
Opening that link reveals the same transaction from the network's perspective:
- Signature
- Accounts
- Instructions
- Fee information
- Confirmation status
- Block information
This is one of the best ways to connect your local code with what validators actually process.
The Mental Model Shift
The biggest lesson I learned wasn't how to transfer SOL.
It was understanding what a transaction really is.
As developers, we're often trained to think in terms of requests and responses.
Client
↓
Server
↓
Database
> Solana requires a different mindset.
Build Transaction
↓
Sign Transaction
↓
Broadcast
↓
Validators Execute
↓
Consensus
The transaction itself becomes the unit of state change.
Once that mental model clicked, concepts like signatures, blockhashes, instructions, and confirmation levels became much easier to understand.
A simple transfer may look trivial on the surface, but it contains nearly every foundational concept needed to build applications on Solana.
And that's what makes it such a powerful learning exercise.
What I'm Exploring Next
Now that I understand the anatomy of a successful transaction, I'm interested in exploring the opposite side of the equation:
- Expired blockhashes
- Failed instructions
- Compute budget limits
- Multi-instruction transactions
- Program interactions
Because sometimes the fastest way to understand how something works is to see how it breaks.
Top comments (0)