Forem: Denil Bhatt

Solana Transactions Are a Distributed Job Processor (Not an API Call)

Denil Bhatt — Tue, 12 May 2026 05:34:13 +0000

🤦‍♂️ The Mistake I Made On Day One

I was just playing around with transactions on Solana last week, and thought of just trying to send a huge amount (500 SOL) to my friend's wallet 💸 — when I only had about 0.5 SOL with me. I for sure knew that the transaction should fail, but I was like — why not just try it out of curiosity. I made the transaction call, the transaction failed. I checked my balance, and it was now 0.499995. 🤯

Huh — that was strange. If the transaction failed, how did my balance drop?

That ◎0.000005 started an itch I had to scratch. 🕵️‍♂️ Coming from Ethereum and Polygon, I assumed I understood what a transaction was. Turns out I had the shape right, but the soul completely wrong.

🤔 First Instinct: "This Looks Like an HTTP Request"

And honestly? It kinda does. When I started building transactions, the structure felt immediately familiar:

Web2 HTTP Request	Solana Transaction
Headers	Message Header
Auth / Bearer Token	Signature
Request Body	Account Keys + Instructions
Request ID	Transaction Signature

That surface-level similarity is real — and it's also the thing that will trip you if you stop there.

Because a Solana transaction is not a request. It's a job submission to a distributed processor.

The Better Analogy: A Distributed Job Queue

Here's how my Web2 brain eventually re-framed it:

Imagine a job/task processor service. You want something done. So you:

Build a request payload containing the job name, parameters, and an access token
Submit it to the service
Get back a jobId
Poll the service for status: queued → processing → success/failure
The service persists the job metadata — payload, traces, logs, output — all of it

Now put on your Web3 goggles and look at the same picture:

const transactionMessage = pipe(
  createTransactionMessage({ version: 0 }),
  (tx) => setTransactionMessageFeePayerSigner(signer, tx),
  // 👇 your session token
  (tx) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),
  (tx) =>
    appendTransactionMessageInstruction(
      getTransferSolInstruction({ // 👈 job name
        source: signer,
        destination,
        amount: amountInLamports,  // 👈 job parameters
      }),
      tx,
    ),
);

const signedTx = await signTransactionMessageWithSigners(transactionMessage);
const signature = getSignatureFromTransaction(signedTx); // 👈 your jobId

See setTransactionMessageLifetimeUsingBlockhash? That's setting your session token — a recent blockhash that acts exactly like a CSRF token with a validity window. It expires in ~60–90 seconds. If your transaction isn't processed in that window, it's dead. No retry, no extension.

The mapping now looks like this:

Job Processor Concept	Solana Equivalent
Job name / Task reference	Instructions
Job parameters	Account Keys
Session token (CSRF)	Recent Blockhash
Access token / Checksum	Signature
JobId	Transaction Signature
Job status (queued → done)	Commitment level
Persisted job metadata	On-chain transaction record

Submitting the job looks like this:

const wireTransaction = getBase64EncodedWireTransaction(signedTx);
await rpc.sendTransaction(wireTransaction, { encoding: "base64" }).send();

You're handing the job off. And now you wait.

👀 Where the Analogy Gets Interesting: Peer Review

In Web2, once the job processor says "done" — you trust it. That's it. Single source of truth.

Solana does something different. And this is the part that genuinely changed how I think about decentralised systems.

When a Leader Node (think: the primary job processor) picks up your transaction and runs it, it packages it into a block — a batch of jobs — and broadcasts that block to the network. 🚚

From here, the validators (the peers) pick up that block, re-execute every transaction independently, and vote on whether the results are valid.

The commitment lifecycle goes like this:

processed → Leader node ran it, block is broadcast
confirmed → 66%+ of validators have voted it valid ✅
finalized → 31+ more blocks have been built on top. It's permanent.

Here's what that looks like in practice, straight from my devnet terminal:

Reading the output above:

Recent Blockhash → the CSRF-style session token, set at build time

Signature 0 → your jobId, returned the moment you submitted

Instruction 0 / Transfer { lamports: 100000000 } → the job definition — what to run, with what parameters

Fee: ◎0.000005 → the cost of execution (we'll come back to this)

Finalized → peer review complete. It's on-chain. It's permanent.

The interesting bit here is Peer Review.

In a Web2 environment, a malicious actor could potentially manipulate the response of a single job processor — intercept it, tamper with it, return a fake success. With Solana, to manipulate a result you'd need to corrupt 66%+ of the entire validator network simultaneously. That's not a bug fix, that's a coordinated attack at civilizational scale.

That's why decentralisation isn't just a philosophy. It's a security model.

⚠️ The Part Nobody Warned Me About: Failure Isn't Free

Let's have a look at this transaction:

Transfer { lamports: 500000000000 } → just goofing around with 500 SOL

Status: Error processing Instruction 0 → states the failure

Transfer: insufficient lamports → that's right, I didn't have enough balance

Fee: ◎0.000005 → wait what? — but you didn't make it through

Transaction failed → ah you know that, still charging me?

Here's what I wish someone had told me upfront:

The network fairly compensates every participant — the Leader Node that ran your batch, the validators that peer-reviewed it. Everyone did work. Everyone gets paid. Whether your transaction succeeded or failed.

That's not a gotcha. It's honest accounting. But it will catch you off guard the first time.

Unlike me — don't make the mistake of assuming that failed transactions might be free.

🧠 The Mental Model, In One Sentence

Solana transactions are like HTTP requests in shape, but distributed job submissions in soul — with a session token that expires, a network of peer reviewers instead of a single server, and a fee structure that charges for effort, not outcome.

🚀 What I'm Building Next

Next week is all about diving deeper into the account model in Solana. Excited to make more mistakes and learn something with each fall.

This is Day 20 of my MLH 100 Days of Solana challenge. I'm a Web2 backend developer exploring Solana purely out of curiosity — and apparently, stubbornness.

Code from this series: github.com/denilbhatt0814/MLH-100-days-of-solana

I've Been Building on Sand. Solana Builds on Bedrock.

Denil Bhatt — Sun, 03 May 2026 11:07:47 +0000

When I first read "everything in Solana is an account" — I had exactly three questions on my mind. 🤔

What does "account" even mean here?
What does "everything" actually look like?
And... why?

If you, like me, come from a Web2 background and live with an assumption that data lives somewhere "magical" ✨ — some lowest layer under the world — you know the feeling. You deploy your backend, your database spins up, and data just... exists. It's not your primary concern. You're thinking about APIs, auth, maybe caching. Storage is already handled — a line item on your AWS bill, baked into your infra cost, invisible by design.

Nobody told you to think about it first hand. So you didn't.

But in Week 2, when I was learning about the fundamental unit of data storage, Solana said: everything is an account. 🤨

Holding	Account Type
Your wallet, SOL balance	System Account
A specific token balance	Token Account
Deployed executable code	Program Account
Program state / stored data	Data Account

Same container, different purpose.

After digesting this, if I had to condense "Account" in one line, I would say:

An account is a persistent data container that stores state, SOL balances, or program code — identified by a unique public key.

Now remember that magical place where Web2 data just exists?

Solana looked me in the eyes and said — "yeah, that's not how this works here."

On Solana, storage isn't free or permanent by default. The protocol enforces a Rent system — a refundable deposit of SOL proportional to the bytes used. 💰

When I heard "accounts pay rent to stay alive on Solana", my mind had two reactions at once:

💡 "Wow, that's a smart way to value your infra and use it wisely."
🤨 "Monetizing the core component of any application? Brilliant business idea."

Both reactions are still alive in me. I haven't resolved the tension. Maybe I don't need to yet.

That's when it hit me. ✨

In Web2, storage takes a back seat — not a concern until you're seriously hunting for optimization.

Solana treats it as a first class citizen. You think about it first, not last.

But here's what's still floating for me: Transactions, Instructions, Programs. I see these words everywhere in the docs. I know they matter. I just don't have the mental model yet — the same way I didn't have one for accounts two weeks ago.

Week 3, I'm coming for you. 🫡

This is part of my #100DaysOfSolana journey with MLH. I'm documenting everything — the clicks, the confusion, and everything in between. Follow along if Web3 has been on your curiosity list.

🐦 Twitter/X · 💻 GitHub · 💼 LinkedIn

Your Signature is Your Identity

Denil Bhatt — Sun, 26 Apr 2026 10:57:25 +0000

Meri chabi, meri pehchan. My key, my identity. Sounds dramatic — until you realize it's literally how identity on Solana works.

Identity in Web2: The World You Know

Say there is a new social media app rolled out this week, and you plan to be a part of it. When you hop on, the first thing you are asked for is to create an account — "your identity" on the platform. You enter a username, set up a password, and voila, you are all set.

Next time you wish to access the platform, you use this combination and are allowed in. Now you can post a pic of your "Sunday Brunch" or share a clip of your "Bali Trip".

Identity on Solana: The Same, But Yours

Identity on a blockchain network such as Solana works similarly, but uses cryptography to let you generate your own username and password — what we call a Public Key and Private Key.

The public key, like a username or social media handle, acts as your identity on the Solana ecosystem, while your private key acts as the password — a proof of ownership of that identity.

The "Forgot Password" Moment

Now let's imagine you lost the password to this social media platform. What happens? You hit "Forgot Password?" The company sends you an email to reset it, and — you have your account back.

For a second, let's analyze what just happened. You lost the keys to your house, cried for help, and "Abracadabra" — someone handed you a key to access it. How? Wasn't it your own house? How could someone else hand you access? Did you actually own it?

There is no "Forgot Password" on Solana. There is no Solana Inc. support team that will fly to your rescue. No one can let you back in. Because no one owns your identity except you.

Okay, But So What?

At this point, you might be thinking — "yaa yaa, I get the idea, identity, ownership, so what??"

Here's what: your Solana identity — the keypair (public/private key) — works across every app on the network without asking anyone's permission. The tokens you hold, the votes you cast, the reputation you build — all of it is tied to one keypair that belongs entirely to you. No app can ban your keypair out of existence. No company can hand someone else your address.

I spent the past five days participating in the 100 Days of Solana challenge by MLH, understanding identity on Solana, and I realised — I never really owned my identity on Web2. But on Solana, it lives in my hands.

Meri chabi, meri pehchan. And I hope now you too understand what it means.