When I started writing code that sends SOL, I treated transactions like API calls. Construct a payload, POST it to the network, wait for a 200 OK. That mental model worked — until it didn't.
Then I realized: a Solana transaction isn't a request. It's a signed check.
🧠 The Analogy
Think of writing a physical check. You fill in who gets paid and how much. You sign it. Someone deposits it. The bank processes it — either the money moves or the check bounces.
A Solana transaction works the same way:
- You write the instruction — "Pay 0.1 SOL from my account to this address"
- You sign it — with your private key (like signing the check)
- You submit it — to the network (like depositing the check)
- The network processes it — atomically, all or nothing
The check analogy breaks down in one important way though: in Solana, you pay the processing fee even if the check bounces.
⚡ The Part That Surprised Me
I crafted a transaction sending 500 SOL from a wallet that only had 2. I disabled preflight simulation so it would reach the network. It failed, obviously. But the 5,000 lamport fee was still deducted.
This is fundamentally different from Web2. A failed HTTP request costs you nothing — the server returns an error and you move on. On Solana, validators executed your instruction, ran your program, determined the outcome, and included the result in a block. That work consumed compute resources, and validators get paid regardless of the outcome.
I covered the technical details — building a transfer tool with commitment tracking, polling for confirmation, forcing failures — in -
But the economic lesson is what stuck with me:
Every transaction is an economic event. It consumes network resources. It has a cost. You pay for execution, not just success.
⚙️ What This Changes
Simulate before you send. The skipPreflight flag exists for edge cases, not everyday development. Most failures can be caught locally — insufficient balance, wrong account ownership, expired blockhash. Check everything before you submit.
Failed transactions are learning tools. The program logs in a failed tx show you exactly where execution stopped, how much compute was consumed, and what error the program returned. I've learned more from forced failures than from successful transfers.
Atomicity is built in, not bolted on. If a transaction has three instructions and instruction 2 fails, instructions 1 and 3 are rolled back too. The fee is still charged. In Web2, you'd write try/catch blocks and compensation logic. On Solana, the runtime guarantees atomicity — but you pay either way.
I wrote about the transaction anatomy -
— signatures, blockhashes, account keys, compiled instructions — and walked through a CLI transfer -
step by step in earlier posts. But the mental model upgrade is simpler than any of those details:
Don't think of a transaction as a request you send. Think of it as a check you sign.
This is a submission for the 100 Days of Solana Writing Challenge, running from 15 May to 22 May.
Top comments (1)
🔥