When I first started learning Solana, transactions felt like magic.
You click "Send", wait a few seconds, and somehow value moves across a decentralised network. But after spending time building and debugging transactions myself, I realised that every Solana transaction has a very clear structure underneath it.
And honestly, understanding that structure made blockchain feel far less mysterious.
A transaction is more than “sending crypto”
Coming from Web2, I initially compared a Solana transaction to an API request.
You send data somewhere, something processes it, and the system changes state.
That analogy helps at first, but it breaks pretty quickly.
A Solana transaction is closer to a signed package of instructions that the network verifies before allowing any state change to happen. It’s atomic too, meaning either everything succeeds or nothing does, similar to a database transaction.
But unlike a normal API request, Solana transactions require cryptographic signatures and expire after a short period of time.
That was one of the first things that surprised me.
The four parts that finally made things click
- Signatures: Proof of authorization
The signature is what proves that the transaction was approved by the owner of the wallet.
Without it, the network rejects the transaction completely.
It reminded me a bit of authentication tokens in Web2, except this is cryptographic proof instead of session-based trust.
When I used the Solana CLI to send SOL between wallets, I was unknowingly generating signatures every single time.
solana transfer 0.01 --allow-unfunded-recipient
At first, this just felt like a command.
Later, I realised I was actually signing an instruction with my private key and asking the network to verify it.
That perspective changed everything for me.
- Instructions: The actual action being requested
Instructions are the real “what should happen” part of the transaction.
For example:
Transfer SOL
Create an account
Interact with a programme.
Mint a token
A single transaction can even contain multiple instructions bundled together.
That was unexpected for me because I originally assumed one transaction always meant one action.
But on Solana, a transaction can coordinate several operations at once.
- Accounts: The data being read or modified
This was probably the biggest mindset shift.
In Web2, I’m used to thinking in terms of databases, tables, and backend-controlled state.
On Solana, everything revolves around accounts.
Transactions specify which accounts they want to interact with, whether those accounts are:
being modified
read from
signed by
or owned by a program
The network checks permissions before allowing anything to happen.
That level of explicitness felt uncomfortable at first, but it also made the system feel transparent.
Nothing is hidden.
- Recent blockhash: A built-in expiration timer
This part confused me initially.
Why does a transaction need a recent blockhash?
Then it clicked: it prevents old transactions from being replayed forever.
A recent blockhash acts like a freshness check. If the transaction takes too long to process, it expires and becomes invalid.
In Web2, API requests usually don’t “expire” because of network state in this way.
That difference really showed me how blockchain systems think differently about trust and validation.
The biggest lesson for me is that a Solana transaction is not just “sending crypto".
It’s a structured, signed request for state changes on a public network.
Once I started understanding signatures, instructions, accounts, and recent blockhashes, transactions stopped feeling like magic and started feeling like systems engineering.
And that’s when Solana really began to make sense to me.
solana #100DaysOfSolana
