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:
- Verify your signature
- Check that the recent blockhash is valid
- Load all the accounts referenced in the transaction
- Execute the instructions
- 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:
-
InstructionErrorthe failure was in instruction execution (not signature verification or blockhash expiry) -
0it was the first instruction (zero-indexed) that failed -
Custom(1)a program-specific error code. For the System Program, code 1 isInsufficientFunds
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: trueunless 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
| Failure type | Reaches chain? | Fee charged? | How to catch it |
|---|---|---|---|
| Invalid signature | No | No | SDK throws before sending |
| Expired blockhash | Sometimes | Sometimes | Preflight simulation |
| Insufficient funds | No (if preflight on) | No | Preflight simulation |
| Program execution error | Yes | Yes |
meta.err after confirmation |
| Compute budget exceeded | Yes | Yes |
meta.err after confirmation |
The most useful debugging habit I've built from Epoch 1: whenever a transaction does something unexpected, paste the signature into Solana Explorer, switch to devnet, and read meta.err and the program logs. It's all there, permanently, for free. The blockchain is a better debugger than console.log ever was.
Day 19 of #100DaysOfSolana. Breaking things on purpose so you don't have to break them by accident.
#100daysofsolana #solana #web3 #blockchain
Top comments (0)