A few days ago, I knew almost nothing about how Solana transactions actually worked. I thought sending a transaction would feel similar to making an API request in a typical backend application — send data, get a response, done. But after building and debugging transactions on Solana devnet, I realized the mental model is very different.

In Solana, you interact directly with a decentralized state machine where every action is signed, validated, recorded on-chain, and eventually finalized by the network. They require cryptographic signatures. They expire after a short time because of blockhash validity. That last part surprised me the most. Transactions are tied to a recent blockhash, which means they cannot stay valid forever.
I started by creating a simple CLI tool that sends SOL on devnet.
One concept that really changed my understanding was commitment levels.
Initially, I assumed a transaction was either successful or failed. But Solana actually has multiple confirmation stages:

processed
confirmed
finalized

I added polling logic to track transactions through each stage.

await waitForCommitment(rpc, signature, "confirmed");
await waitForCommitment(rpc, signature, "finalized");

That made me realize blockchain confirmations are not instant yes/no responses. The take time, a transaction that is confirmed is updated to finalized only after 30+ blocks are stacked in front of it. This only takes few seconds. They represent increasing confidence from the network.
Failed Transactions Taught Me More Than Successful Ones. At the end we get the transaction signature providing all the details of the transaction.

One of the most useful exercises was intentionally breaking transactions.
What surprised me was that failed transactions can still consume fees. That’s why balance checks before sending are important.

The biggest lesson for me was understanding that transactions are not just “requests.” They are signed, time-sensitive that become part of a permanent public ledger.

I still have a lot to learn, especially around programs, PDAs, and full dApp architecture, but building and debugging transactions made Solana feel much more real and approachable.