DEV Community

Elizabeth Afolabi
Elizabeth Afolabi

Posted on

What Failed Transactions Taught Me About Solana

A few days ago, Solana transactions still felt abstract to me.

I understood the general idea:
sign a transaction -> send it to the network -> it gets processed.

But during this phase of the challenge, things started becoming more concrete.

Especially when I began inspecting transaction confirmations, experimenting with transfer tooling, and intentionally triggering failed transactions.

That’s when Solana stopped feeling like “crypto magic” and started feeling more like engineering.

My Initial Mental Model

At first, I thought of transactions almost like simple requests:

send SOL from A -> B

And that was basically it.

But after exploring transaction anatomy more deeply, I realized a Solana transaction is much more structured than that.

It’s:

  • a signed request
  • containing instructions
  • executed by programs
  • against accounts
  • processed by a distributed validator network

The official Solana transaction docs also helped clarify how signatures, instructions, and accounts are structured internally:
https://solana.com/docs/core/transactions

That mental shift changed how I started looking at the system.

One thing that made transactions easier to understand was comparing them to requests in traditional applications.

Not exactly the same, but close enough to create a mental bridge.

You construct a request, send it to a distributed network, wait for processing, and eventually receive confirmation back.

But unlike a normal API request:

  • transactions require signatures
  • they expire after some time
  • validators participate in confirming them
  • and failure can still cost money

Failed Transactions Changed My Perspective

I intentionally triggered an insufficient funds error expecting the transaction to simply reject without consequences.

Instead, I learned something important:

failed transactions can still consume fees.

That caught me off guard.

Even though the transfer failed, validators still processed the transaction and performed work, so fees were still deducted.

That completely changed how I thought about blockchain transactions.

In most frontend workflows, a failed action usually just returns an error.

Here, failure still has a cost.

And suddenly concepts like validation, simulation, balance checks and transaction design started feeling much more important.

Screenshot of a failed transaction output

Confirmation States Made More Sense Than I Expected

Another concept that stood out to me was transaction confirmation.

I learned that transactions move through stages like:

  • Processed
  • Confirmed
  • Finalized

At first, these looked like simple status labels.

But they actually represent increasing confidence from the network.

A validator first processes the transaction, then the network reaches supermajority agreement.

Then enough blocks are added afterward that reversal becomes practically impossible.

I still don’t fully understand concepts like polling and finality yet, but this was the first time transaction processing started feeling like a real distributed system instead of just a black box.

Screenshot of the progress of a transaction being finalized on the terminal using solana CLI

One Detail That Really Stuck With Me

Another thing that genuinely surprised me was learning this:

Creating a wallet does not automatically create an on-chain account.

The address exists immediately because it’s derived from a keypair.

But the actual account only exists on-chain once it’s funded.

That distinction felt subtle at first, but it changed how I think about accounts on Solana.

Storage and state feel much more explicit here than I initially expected.

What Changed for Me

The more I explored transactions, the less Solana felt like “just sending crypto.”

It started feeling more like interacting with a distributed system with strict rules around state, validation, execution and confirmation.

I also became much more aware of the complexity underneath even simple transfers.

Before this, a transaction felt like:

click send and wait

Now I see:

  • validators processing requests
  • confirmation stages
  • execution rules
  • signatures
  • fees
  • and failure handling

all happening underneath something that initially looked simple.

I still don’t fully understand every part of the system yet, but transactions no longer feel abstract to me anymore.

And honestly, that’s probably the biggest shift from this week.

Top comments (0)