Your try/catch Won't Save You on Solana (and That Cost Me Lamports to Learn)

In Web2, failed requests are free.

You misconfigure a Stripe call, Stripe says 400 Bad Request, you fix it, you try again. No charge. The server rejected your request before doing any real work, or if it did do work, the rollback is Stripe's problem, not yours.

I assumed Solana worked the same way. It doesn't. And I found out the expensive way , well, "expensive" in a devnet sense, but the lesson transferred.

The day I broke things on purpose

On Day 19 of #100DaysOfSolana, the challenge was to deliberately trigger failed transactions and inspect them. Not handle them gracefully. Break them intentionally, on purpose, and then read the wreckage.

I generated a fresh keypair with zero SOL:

solana-keygen new --outfile /tmp/broke-wallet.json --no-bip39-passphrase --force

Then tried to send from it:

solana transfer --keypair /tmp/broke-wallet.json $(solana address) 1 \

  --url devnet --allow-unfunded-recipient

Expected: error message, nothing happens.


Got: error message, nothing happens. ✓

Okay, that one the CLI caught locally before anything reached the network. Let me try something that actually hits the chain. I wrote a small script that skips preflight simulation the safety check that normally catches failures before sending and forces a transaction through that's guaranteed to fail on-chain:

import {

  createSolanaRpc, devnet, address,

  createKeyPairSignerFromBytes,

  pipe, createTransactionMessage,

  setTransactionMessageFeePayerSigner,

  setTransactionMessageLifetimeUsingBlockhash,

  appendTransactionMessageInstruction,

  signTransactionMessageWithSigners,

  getBase64EncodedWireTransaction,

  lamports,

} from "@solana/kit";

import { getTransferSolInstruction } from "@solana-program/system";

import { readFile } from "node:fs/promises";



const rpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));



const keyData = JSON.parse(await readFile(

  `${process.env.HOME}/.config/solana/id.json`, "utf-8"

));

const sender = await createKeyPairSignerFromBytes(

  new Uint8Array(keyData)

);



const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();



// Trying to send WAY more than the wallet holds

const tx = await pipe(

  createTransactionMessage({ version: 0 }),

  m => setTransactionMessageFeePayerSigner(sender, m),

  m => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m),

  m => appendTransactionMessageInstruction(

    getTransferSolInstruction({

      source: sender,

      destination: address("11111111111111111111111111111112"),

      amount: lamports(999_000_000_000n), // 999 SOL — I definitely don't have this

    }),

    m

  ),

  m => signTransactionMessageWithSigners(m),

);



// skipPreflight: true — bypass the safety check, let it fail on-chain

const signature = await rpc.sendTransaction(

  getBase64EncodedWireTransaction(tx),

  { skipPreflight: true, encoding: "base64" }

).send();



console.log("Signature:", signature);

The script ran. It printed a signature. The transaction landed on-chain.

I checked the result:

solana confirm -v [THE_SIGNATURE] --url devnet

Transaction executed in slot 312847103:

  Status:   Error: InstructionError(0, Custom(1))

  Fee:      5000 lamports

  Compute:  3436 units consumed



  Account 0 (sender):

    Before: 1,800,000,000 lamports

    After:  1,794,995,000 lamports  ← wait

The transfer didn't go through. But my balance dropped by 5,000 lamports.

Why this happens (and why it matters more than you think)

When your transaction reaches the Solana network, validators do real work. They:

1. Verify your signature


2. Check that the recent blockhash is valid


3. Load all the accounts referenced in the transaction


4. Execute the instructions


5. If execution fails, roll back state changes — but the fee is already gone

The fee compensates validators for steps 1–4. They did that work. They get paid. Your instruction failing at step 4 doesn't undo steps 1–3.

This is fundamentally different from a failed HTTP request.

When your API call to Stripe returns a 400, Stripe either rejected it before doing anything (client-side validation) or caught it in a transaction and rolled back (database atomicity). Either way, you don't get billed per attempt.

On Solana, you do. Every failed on-chain transaction costs a fee. On mainnet, the base fee is still only ~0.000005 SOL per transaction — not a lot. But if you're running a production app that sends transactions in a loop and you have a bug that causes systematic failures? That adds up. And you can't get it back.

The thing that actually saves you: preflight simulation

Solana's RPC has a simulation endpoint. Before sending a transaction for real, you can run it in a sandboxed environment validators simulate execution, return what would happen (including errors), and charge you nothing.

This is what skipPreflight: false (the default) does automatically when you call sendTransaction. It's why my first attempt (the CLI transfer from an empty wallet) failed locally the SDK simulated it first and caught the error before it ever touched the network.

By setting skipPreflight: true in my script, I deliberately bypassed that safety net.

The lesson: preflight simulation is not optional on Solana. It's the economic gatekeeper.

In Web2 terms: it's like client-side form validation. Yes, you should also validate on the server (the network will reject truly invalid transactions regardless). But the form validation is what stops you from wasting a round-trip and on Solana, that round-trip has a real lamport cost.

// Always let preflight run (this is the default don't override it unless you know why)

const signature = await rpc.sendTransaction(

  getBase64EncodedWireTransaction(tx),

  { encoding: "base64" }

  // skipPreflight defaults to false ✓

).send();

What meta.err actually tells you

When a transaction fails on-chain, the error lives in the meta.err field of the transaction record. It looks like this:

InstructionError(0, Custom(1))

Breaking this down:

• 
  InstructionError the failure was in instruction execution (not signature verification or blockhash expiry)


• 
  0 it was the first instruction (zero-indexed) that failed


• 
  Custom(1) a program-specific error code. For the System Program, code 1 is InsufficientFunds
  

As you start writing your own programs, you define your own custom error codes. When something fails in production, this field tells you exactly which instruction, in which program, threw which error. It's your stack trace.

The mental model shift

Here's the reframe that made everything click for me:

In Web2, errors are free information. You throw them, catch them, log them, retry. The cost is compute time, which is cheap and yours.

On Solana, errors that reach the chain have a price tag. Not a punishing one, we're talking fractions of a cent. But the architecture forces you to think about correctness before submission, not just after.

This changes how you write Solana code:

• 
  Validate before submitting. Check balances, check account state, check instruction data, off-chain, for free, before sending anything.


• 
  Trust preflight. If simulation catches an error, fix it. Don't route around it with skipPreflight: true unless you're doing something very deliberate (like stress-testing failure modes on devnet).


• 
  Treat failed transactions in your logs as real events. They cost real fees. They're worth understanding, not just re-trying blindly.

Quick reference

The most useful debugging habit I've built from Epoch 1: whenever a transaction does something unexpected, paste the signature into . Breaking things on purpose so you don't have to break them by accident.

#100daysofsolana #solana #web3 #blockchain