Over the past few days in #100DaysOfSolana, I went from knowing almost nothing about Solana transactions to building my own CLI transfer tool, tracking transaction confirmations in real time, and debugging failed on-chain transactions.

Coming from a backend/web2 background, Solana transactions initially felt confusing. Terms like signatures, blockhashes, commitment levels, and atomic state changes sounded very different from the APIs and databases I was used to.

But after building and breaking transactions myself, something finally clicked.

In this post, I want to explain Solana transactions from the perspective of a backend developer.

⸻

The Mental Model Shift

At first, I treated a Solana transaction like an HTTP request:
`POST /transfer

{

"from": "...",

"to": "...",

"amount": 0.01

}`

But that mental model is incomplete.

A Solana transaction is closer to a signed, atomic database transaction that gets executed by a decentralized network.

Unlike a normal API request:

• there is no centralized server
• every transaction must be cryptographically signed
• transactions expire quickly
• failures still cost fees
• consensus happens in stages

That last point surprised me the most.

⸻

Transaction Confirmation Is Not Binary

In web2 systems, requests are usually either:

• pending
• successful
• failed

But on Solana, transactions move through multiple commitment levels:

Processed

A validator received and processed the transaction.

This is similar to:

“The server accepted your request.”

But it is not finalized yet.

⸻

Confirmed

A supermajority of validators voted on the block containing your transaction.

This is effectively:

“The network agrees your transaction succeeded.”

Interestingly:

no confirmed transaction in Solana history has ever been reversed.

⸻

Finalized

31+ additional blocks were built on top of your transaction.

At this point, the transaction is considered irreversible.

This feels similar to:

• replicated database commits
• durable writes
• globally finalized state

⸻

Building My Own Transfer Tool

One of the most useful exercises was building a reusable CLI transfer tool using:

• Node.js
• @solana/kit
• Solana CLI keypairs

Instead of manually typing transfer commands every time, the tool:

• accepts recipient + amount arguments
• checks balances
• signs transactions locally
• submits transactions to devnet
• tracks confirmation progress
• prints Explorer links node transfer.mjs <RECIPIENT> 0.01 Terminal output: `Solana Transfer Tool ==================== Connected to Solana devnet.

Status: processed ✅
Status: confirmed ✅
Status: finalized ✅

Transaction successful!`
his felt very similar to building internal tooling around payment APIs in web2.

Except this time:

• there was no Stripe
• no backend server
• no payment gateway

The transaction went directly to the blockchain network.

⸻

Failed Transactions Taught Me More Than Successful Ones

One thing I underestimated:

failed transactions are incredibly educational.

For example, I intentionally tried sending more SOL than my balance:
node transfer.mjs RECIPIENT 999
Result:
Transaction failed:
Insufficient balance...
I also learned:

• failed transactions still consume fees
• blockhashes expire
• commitment levels matter
• RPC polling is essential for good UX

This changed how I think about blockchain applications.

⸻

The Biggest Difference From Web2

The biggest mindset shift for me was this:

In web2:

servers own state

In Solana:

the network owns state

Your application becomes more like:

• a transaction builder
• a signing interface
• a state interpreter

instead of a traditional CRUD backend.

That changes everything.

⸻

Final Thoughts

A week ago, Solana transactions looked intimidating.

Now they feel surprisingly elegant.

Once I stopped trying to force blockchain into traditional web2 mental models, the architecture started making sense:

• atomic state changes
• cryptographic authorization
• distributed consensus
• deterministic execution

I still have a lot to learn, but building and debugging real transactions helped far more than just reading documentation.

If you’re a backend developer exploring Solana for the first time:
my biggest recommendation is simple:

build small tools yourself.

That is when the concepts really start to click.

Solana #Blockchain #Web3 #100DaysOfSolana