DEV Community: Hauwa Ibrahim

Solana’s account model isn’t scary. It’s just a filing cabinet.

Hauwa Ibrahim — Sat, 23 May 2026 03:13:49 +0000

Hey, Web2 friend.

You’ve built REST APIs. You’ve stored sessions in Redis. You’ve wrestled with PostgreSQL at 3 AM.

Now you’re peeking into Solana, and someone hit you with the phrase: “Everything is an account.”

Your first thought is probably: “Uh oh. Another abstract blockchain thing I have to memorize.”

I promise, it’s not that bad.

In fact, if you’ve ever used a filesystem or a key-value store, you already understand 80% of Solana’s account model. Let me show you what I mean.

One model to rule them all

Ethereum has two types of accounts:

Externally owned accounts (wallets)
Contract accounts (smart contracts)

Solana says: “Nah, that’s too complicated. Let’s just have one.”

On Solana, everything is an account.

Your wallet? Account.

A program (smart contract)? Account.

A single token balance? Also an account.

An NFT’s metadata? You guessed it. Account.

The whole blockchain is basically a giant key-value store.

Key: a 32-byte address (looks like a long random string)
Value: the account itself

That’s it. Flat. Simple. No nesting. No inheritance. Just a big hash map in the sky.

What’s actually inside an account?

Every account on Solana has exactly five fields. No more, no less.

Here’s what one looks like (simplified):

{
  "lamports": 890000,
  "data": [],
  "owner": "SystemProgram",
  "executable": false,
  "rent_epoch": 18446744073709551615
}

Let’s walk through them like normal humans.

🪙 lamports – the “storage rent” piggy bank

lamports is just SOL measured in tiny units (1 SOL = 1 billion lamports).

To keep an account alive on Solana, it needs a minimum balance. Think of it like a security deposit so you don’t spam the network with junk data.

In Web2 terms: you pay AWS for EBS storage. Same vibe.

📦 data – the actual stuff

This is a byte array. Could be anything.

If the account is a program, this holds executable code.
If it’s a data account, this holds JSON, numbers, token balances, or whatever the app needs.

No separate database. No ORM. Just bytes.

👑 owner – who’s allowed to touch this?

This is the only program that can modify the account’s data or spend its lamports.

Anyone can send lamports to the account. But changing the data? That requires permission from the owner.

Web2 analogy: only the root user or the file owner can chmod a file.

🧠 executable – is this code or data?

true → this account is a program (smart contract)
false → this account is just holding data

That’s it. No third option.

⏳ rent_epoch – ignore this

Honestly? Ignore it. It’s deprecated. For all modern accounts, it’s just set to the maximum number. Move along.

The part that surprises most Web2 devs

Here’s where Solana flips the script.

Programs don’t store their own state.

Wait, what?

In Web2, your server (program) keeps things in memory or connects to a database. The code and the data live in the same place conceptually.

On Solana:

Program account = the logic (like a read-only function)
Data account = the state (like a row in a table)

They are separate.

A program can read and write to many data accounts, but it never “remembers” anything on its own between transactions.

Think of a program like a pure function. Give it data accounts as input. It gives you new data accounts as output. No hidden globals. No singletons.

This is weird at first. But it’s also beautiful.

It’s why Solana can run thousands of transactions in parallel — because transactions that touch different data accounts don’t conflict.

A tiny note on rent (but not scary rent)

Solana used to charge “rent” over time. That’s gone.

Now you just need to be rent-exempt.

That means your account holds enough lamports for its data size. For a basic account with no extra data, that’s about 0.00089 SOL (roughly a fraction of a penny).

Pay it once. Account stays forever. No monthly bills.

So… what do I actually remember?

If you know this from Web2	You already understand Solana
Key-value store (Redis, Dynamo)	The whole blockchain
File permissions (chown, chmod)	The `owner` field
Executable vs. data file	The `executable` boolean
Paying for disk space	`lamports` for rent exemption
Stateless functions	Programs don’t store state

You’ve got this

The account model is the foundation of everything on Solana.

Tokens? Accounts.

NFTs? Accounts.

Governance votes? Also accounts.

Once you stop thinking in “classes and objects” and start thinking in “files and permissions,” Solana becomes much less intimidating.

You don’t need to write a smart contract tomorrow.

Just sit with the model for a day.

Look up an account on Solana Explorer.

See those five fields with your own eyes.

That’s the moment it clicks.

And when it does? You’re officially thinking like a Solana dev.

Happy building

Your Node.js Version Will Break Solana (And How to Fix It)

Hauwa Ibrahim — Thu, 21 May 2026 21:30:51 +0000

The Headline That Would've Saved Me 72 Hours

Let me start with a confession:

I spent three days debugging code that wasn't broken.

The code was fine. The logic was correct. The Solana API was working.

The problem? My Node.js version.

And nobody told me.

So here I am, three days later, writing what I wish someone had written for me.

The Setup: This Should've Been Easy

I'm a developer. Not a blockchain expert. Not a crypto bro. Just web 2 developer curious about web 3.

I wanted to build something simple for my #100DaysOfSolana challenge:

Take a Solana address
Fetch its balance
Display account info
Done. 15 minutes. Maybe 30.

I found the code in the Solana tutorials provided:

import { createSolanaRpc, address } from "@solana/kit";

const rpc = createSolanaRpc("https://api.devnet.solana.com");
const targetAddress = address(process.argv[2]);
const { value: balanceLamports } = await rpc.getBalance(targetAddress).send();
console.log(`Balance: ${balanceLamports / 1_000_000_000} SOL`);

Clean. Simple. Modern JavaScript.

I ran it:

node explorer.mjs TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

And then the nightmare began.

Day 1: The First Crash

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '/home/.../node_modules/@solana/kit/'

My reaction: "Oh, dumb mistake. Forgot to install it."

npm install @solana/kit

The result:

npm warn EBADENGINE Unsupported engine {
  package: '@solana/codecs-core@2.3.0',
  required: { node: '>=20.18.0' },
  current: { node: 'v18.20.8' }
}

My reaction: "A warning. Whatever. It'll probably work."

Spoiler alert: It did not work.

Day 2: The Spiral

I spent hours Googling and ChatGPTing lol. Every answer sent me down a different rabbit hole:

"Try clearing your cache"
"Reinstall node_modules"
"Check your package.json"
"Use a different RPC endpoint"

Nothing worked.

I checked my package.json:

{
  "dependencies": {
    "@solana/kit": "^0.0.0"
  }
}

Wait. ^0.0.0?

That's not a real version. That's a placeholder.
So I fixed it:

{
  "dependencies": {
    "@solana/kit": "^6.5.0"
  }
}

rm -rf node_modules package-lock.json
npm install
node explorer.mjs TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Same error. Nothing changed.

I was losing my mind.

Day 3: The Breakthrough

After hours of debugging, I re-read that warning from Day 1:

required: { node: '>=20.18.0' },
current: { node: 'v18.20.8' }

What if... the warning was actually the error?

I ran:

node --version
# v18.20.8

Then I installed Node 20:

nvm install 20
nvm use 20
node --version
# v20.18.0

Then I ran my script one more time:

node explorer.mjs TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

=== Solana Account Explorer ===


Address:    TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Balance:    11.977573357 SOL (11977573357 lamports)
Owner:      BPF Upgradeable Loader (BPFLoaderUpgradeab1e11111111111111111111111)
Executable: true
Data size:  36 bytes
Rent epoch: 18446744073709551615
Data (hex): 0200000027f190b1d3af98b8ce714c44e8cadff9f8fc45cb8e5fac4202eff8110d97dd37

IT WORKED.

Three days. 72 hours. For a few line script.

All because I didn't believe the warning.

Why This Happened (The Real Explanation)

Here's what I learned that no tutorial told me:

There Are Two Solana JavaScript Libraries

Library	Node.js Required	Status
`@solana/web3.js` (v1)	Node 10+	Old but stable
`@solana/kit` (v2+)	Node 20+	New, modern, faster

I was trying to use the NEW library on an OLD Node version.

It's like trying to run a PS5 game on a PS4. The disc fits. The box looks similar. But it will never work.

The Warning Was Actually The Error

Web2 developers (like me) are trained to ignore warnings. "It's just a warning. Your code will still run."

In Web3, the warning IS the error.

When a Solana package says node: '>=20.18.0', it means it. No negotiation. No "probably fine." It requires features that literally don't exist in Node 18.

The Fix (In 3 Commands)

If you're reading this because you're stuck where I was, here's what you do:

# 1. Install nvm (Node Version Manager) if you don't have it
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

# 2. Install and use Node 20
nvm install 20
nvm use 20

# 3. Make sure your package.json has a REAL version
npm install @solana/kit@latest

Then run your script again.

If it still doesn't work, delete node_modules and package-lock.json and reinstall:

rm -rf node_modules package-lock.json
npm install

The Prevention Checklist

Before you write a SINGLE line of Solana code, do this:

☐ Check your Node version: node --version
☐ If it's below 20(or the latest node version), upgrade NOW
☐ Install nvm so you can switch versions easily
☐ Read ALL warnings. They're not suggestions.
☐ Verify your package.json has real versions (no ^0.0.0)

The Working Code (Finally)

Here's my complete Solana account explorer. It's simple. It works. And it will save you three days.

import { createSolanaRpc, address } from "@solana/kit";

const RPC_URL = "https://api.devnet.solana.com";
const rpc = createSolanaRpc(RPC_URL);
const inputAddress = process.argv[2];

if (!inputAddress) {
  console.error("Usage: node explorer.mjs <SOLANA_ADDRESS>");
  process.exit(1);
}

try {
  const targetAddress = address(inputAddress);

  // Get balance
  const { value: balanceLamports } = await rpc.getBalance(targetAddress).send();
  const balanceSol = Number(balanceLamports) / 1_000_000_000;

  // Get account info
  const { value: accountInfo } = await rpc
    .getAccountInfo(targetAddress, { encoding: "base64" })
    .send();

  const KNOWN_PROGRAMS = {
    "11111111111111111111111111111111": "System Program",
    "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA": "Token Program",
    "TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb": "Token-2022 Program",
  };

  console.log("\n=== Solana Account Explorer ===\n");
  console.log(`Address:    ${inputAddress}`);
  console.log(`Balance:    ${balanceSol} SOL`);

  if (!accountInfo) {
    console.log(`Status:     Account not found on-chain`);
  } else {
    const ownerLabel = KNOWN_PROGRAMS[accountInfo.owner] || accountInfo.owner;
    console.log(`Owner:      ${ownerLabel}`);
    console.log(`Executable: ${accountInfo.executable}`);
    console.log(`Data size:  ${accountInfo.data[0]?.length || 0} bytes`);
  }

  console.log(`\n🔗 Explorer: https://explorer.solana.com/address/${inputAddress}?cluster=devnet`);
} catch (error) {
  console.error("Error:", error.message);
  process.exit(1);
}

What I Learned (And What You Should Know)

For Web2 Developers Coming to Web3:

Node version matters. Like, REALLY matters. Not "recommended." Required.
Read the warnings. In Web3, warnings are usually errors in disguise.
Install nvm TODAY. Switching Node versions takes 2 seconds. Not having nvm costs days.
There are two Solana libraries. Know which one you're using and what it needs.
Three days of debugging is normal. Don't quit. Everyone goes through this.

The Bottom Line

Your Node.js version WILL break Solana.

Not "might." Not "sometimes." It will break it.

But now you know the fix. And it's simpler than you thought:

Upgrade to latest Node version.

That's it. That's the article.

(I wish someone had just told me that on Day 1.)

Your Turn

Are you doing #100DaysOfSolana? Stuck on a similar error?

Here's what I need you to do right now:

node --version

If it doesn't say v20.x.x or higher, stop everything and upgrade.

Then come back and build something awesome.

I'm documenting my entire #100DaysOfSolana journey. Follow along for more hard-earned lessons, debugging stories, and working code.

Questions? Got your own debugging horror story? Drop a comment or find me on [https://x.com/hxrh__].

Don't hesitate to share this article because it will only cost 4 minutes of reading time and debugging time of 3 days saved. Thank you

I Got a Green Tick. But What Just Happened?

Hauwa Ibrahim — Tue, 19 May 2026 20:16:56 +0000

The first time I got a confirmed transaction on devnet, I felt great for about 10 seconds.

Then I thought: I have no idea what actually just happened.

I'd been treating transactions like a black box. Type address, type amount, hit send, done. But that stops working the moment something breaks — or the moment you try to build anything beyond a basic transfer.

So I went and figured it out. Turns out a Solana transaction is made of four things. Once you see what each one does, a lot of other stuff clicks into place.

The four parts

Instructions — what you want to do
Accounts — what data will be touched
Signatures — proof of authorization
Recent blockhash — a built-in expiry stamp

That's it. Let's go through them.

Instructions

An instruction is the action. It says: call this program, with these inputs.

For a basic SOL transfer, the instruction calls Solana's System Program — a built-in program that handles things like moving SOL between wallets. You don't deploy it, it's just there.

The thing that surprised me: one transaction can hold multiple instructions. You could transfer SOL, create an account, and call another program — all in one shot. And it's all-or-nothing. Either every instruction succeeds or the whole transaction fails. No partial results.

Accounts

In Solana, almost everything is an account — your wallet, a token balance, a deployed program. The whole network state is basically one giant table where every row has an address and some data.

When you write an instruction, you have to declare every account it will touch upfront — even ones you're only reading. You also mark each one as writable or read-only, and whether it needs to sign.

This felt like extra work at first. But the reason is smart: Solana uses that list to figure out which transactions can run in parallel. No shared accounts = no conflict = process them at the same time. It's a big part of why Solana can handle so many transactions per second.

The recent blockhash

Every transaction has to include a recent blockhash — a hash of a block that was produced recently on the chain.

It does two things.

First, replay protection. Without it, someone could take your signed transaction and submit it again later. The blockhash ties the transaction to a specific moment, so the network rejects anything that references an old one.

Second, expiry. A blockhash is only valid for about 150 blocks — roughly 60 to 90 seconds. After that window, the transaction is dead. You'd need a fresh blockhash and start over.

This is where Solana diverges from anything in Web2. A database transaction doesn't expire. You can open one, walk away, come back. Solana transactions are more like a signed cheque with an expiry date on it — legitimate signature, but useless after the window closes.

Practical note: fetch the blockhash as late as possible, right before you send.

Signatures

Before a transaction is broadcast, it gets signed with your private key. Validators verify the signature against your public key before running anything.

If the transaction was tampered with after signing, the signature won't match and it gets rejected.

Two things worth knowing:

Transactions can need multiple signatures. Some programs require both parties to sign. Multisig setups require a minimum number of co-signers.

The signature is the transaction ID. That long string in the Explorer URL? That's not a separately generated ID — it's the actual cryptographic signature. Every transaction ID on Solana is its own proof of authorization.

Go look at one on Explorer

Open any of your devnet transactions on Solana Explorer. You'll see:

Account Inputs — every account, labeled writable or read-only
Instructions — each one expanded with its program and data
Signatures — at the bottom of the page

Map what you see back to the four parts above. It lands differently when the transaction on screen is one you sent yourself.

The one thing to take away

A Solana transaction isn't just a request. It's a signed, time-limited, all-or-nothing bundle that declares its own authorization and expiry before it hits the network.

Once that settled in for me, a lot of things that seemed weird about Solana started making sense.

Part of my #100DaysOfSolana journey.

[Boost]

Hauwa Ibrahim — Mon, 18 May 2026 18:57:45 +0000

Syed Ahmer Shah

May 16 '25

How AI is Revolutionizing the Coding Workforce in 2025

#ai #programming #ahmershah #ahmershahdev

323

3 min read

From CLI Commands to My First Solana Transfer Tool

Hauwa Ibrahim — Sat, 16 May 2026 21:47:51 +0000

By this point in the #100DaysOfSolana course, I had already explored a few different aspects of Solana, not just the CLI. But when I first started experimenting, I was mainly running one‑off CLI commands on devnet:

solana transfer <recipient> <amount>

It worked, but it felt awkward. Each time I wanted to send SOL I had to type in the recipient and the amount again, with no balance checks or helpful feedback — just bare commands.

On Day 17, the course pushed me to go further: instead of repeating raw CLI commands, I built my own Node.js script. Now I can run:

node transfer.mjs <recipient> 0.05

The recipient and amount are passed in as arguments, and the script handles the rest — checking balances, sending the transaction, and even giving me a link to Solana Explorer. That was the moment things started to click. I wasn’t just typing commands anymore, I was building a tool I could reuse.

The Struggle

At first, I thought it would be straightforward. But I quickly ran into issues:

Node v12 didn’t support modern syntax like ?? and ?..
Even after upgrading, I hit the dreaded error:

  Transfer failed: No random values implementation could be found.

Debugging felt endless. I was learning Web3 concepts while also fighting with Web2 runtime quirks.

The Breakthrough

The breakthrough came when I realized the Solana kit I was using expected browser‑like APIs. Node didn’t expose them globally. So I patched my environment:

import { webcrypto } from "node:crypto";
globalThis.crypto = webcrypto;

// Polyfill CustomEvent for Node.js < 18.7
if (typeof CustomEvent === "undefined") {
  globalThis.CustomEvent = class CustomEvent extends Event {
    constructor(type, options = {}) {
      super(type, options);
      this.detail = options.detail ?? null;
    }
  };
}

Suddenly, the randomness error disappeared. My script connected, checked balances, built transactions, and confirmed them with a link to Solana Explorer.

The Result

Now I have a reusable CLI transfer tool that:

Accepts recipient + amount as arguments
Checks my balance before sending
Reports the result with a signature and Explorer link
Shows my updated balance after the transfer

What started as a one‑off CLI experiment became a proper utility — something I can reuse, extend, and share.

My Takeaway

Web3 isn’t magic. It’s just APIs, runtimes, and debugging like any other stack. The difference is that every bug you fix teaches you something deeper about how blockchains work.

If you’re a web or mobile developer curious about Solana, start small. Wrap a CLI command in code. Debug the errors. Before you know it, you’ll have built your own tool — and you’ll understand Solana a lot better.

I went from typing raw commands to building my first Solana transfer tool. And the best part? It feels like the beginning of something bigger.

My Solana Journey: Week Two

Hauwa Ibrahim — Mon, 11 May 2026 19:45:06 +0000

When I first started exploring Solana, I wasn’t sure what blockchain data would look like. I imagined something abstract and hidden away, but the reality was surprisingly transparent. Every time someone sends SOL, creates a token, or interacts with a program, it’s recorded as a transaction that anyone can look up. Seeing that history unfold in Solana Explorer made the “public database” idea click in a very real way. It’s both fascinating and a little intimidating to realize how open the system is.

One of the biggest breakthroughs for me was understanding what a signature and a slot mean. At first, those terms felt cryptic, but once I connected them to how transactions are verified and ordered, it started to make sense. That moment of clarity was exciting—it felt like peeling back a layer of mystery.

Another surprise was realizing that every wallet on Solana is actually an account. That framing helped me see the network less like a collection of disconnected addresses and more like a structured system where each account has its own state and history.

That said, I’m still figuring out what exactly a transaction entails beyond just “sending SOL.” I’ve interacted with Solana Explorer, but I want to dive deeper into how program interactions are represented and what all the fields mean. There’s a lot of detail in the RPC responses that I haven’t fully decoded yet.

What’s next for me? I want to learn more about reading on-chain data programmatically and compare it to working with traditional APIs. I suspect the differences will be eye-opening, especially around how state is managed and queried.

Identity on Blockchain: How It Differs from the Traditional Web (with a Focus on Solana)

Hauwa Ibrahim — Fri, 01 May 2026 20:30:22 +0000

Over the past week, I started learning about blockchain, and one of the first concepts I encountered was identity. In our everyday lives, identity is the way we prove who we are. Governments issue ID cards with photos and biometrics, banks assign account numbers with passwords, and online platforms like Google or Facebook give us usernames and passwords to access services. These are all forms of identity, but they rely on centralized authorities—institutions that validate and store our information.

On the internet, identity is often tied to accounts managed by large corporations. A Google account, for example, lets you sign in to countless applications, but Google ultimately controls that identity. If they revoke access, you lose it. This model works, but it raises questions about privacy, ownership, and control. Blockchain networks, however, introduce a fundamentally different way of thinking about identity.

How Identity Works in Blockchain
At its core, blockchain identity is based on cryptography. Instead of usernames and passwords stored by a company, blockchain identity is defined by a keypair: a public key and a private key.

Public Key: This is like your address. On Solana, it’s a long string of characters that uniquely identifies you on the network. Anyone can see it, and it’s used to receive tokens, interact with smart contracts, or participate in decentralized applications (dApps).

Private Key: This is your secret. It proves ownership of the public key and allows you to sign transactions. If someone else gains access to your private key, they effectively become you on the blockchain.

This system is similar to having a bank account number (public key) and a PIN (private key), but with one crucial difference: no central authority issues or controls these keys. You generate them yourself, and ownership is entirely in your hands.

Why Blockchain Identity Is Different
The difference between blockchain identity and traditional web identity lies in decentralization and self-sovereignty.

Ownership: On the traditional web, your identity is managed by platforms. On blockchain, you own your identity outright. Your keys are generated locally, and no one can revoke them.

Portability: A Google account works across Google services, but not outside them. A blockchain identity, however, is portable across the entire network. On Solana, the same public key can interact with hundreds of dApps, from decentralized finance (DeFi) platforms to NFT marketplaces, without needing separate logins.

Trustless Verification: Traditional identity requires trust in institutions. Blockchain identity relies on cryptographic proof. When you sign a transaction with your private key, the network can mathematically verify it without needing to “trust” a third party.

Privacy: On the web, accounts are tied to personal information—emails, phone numbers, sometimes even government IDs. On blockchain, your identity is pseudonymous. Your public key doesn’t reveal your name or personal details unless you choose to link them.

Identity on Solana
Solana, a high-performance blockchain, takes these principles and applies them at scale. Because Solana is designed for speed and low transaction costs, identity on Solana is not just secure but also highly practical.

Wallets as Identity: On Solana, your identity is represented by your wallet. Popular wallets like Phantom or Solflare generate and manage your keypair. When you connect your wallet to a dApp, you’re proving your identity by signing with your private key.

Single Sign-On for Web3: Instead of creating accounts with usernames and passwords, Solana users simply connect their wallet. This acts as a universal login across the ecosystem. It’s like having one identity that works everywhere, but without a corporation in control.

Programmable Identity: Solana’s smart contracts allow developers to build applications that recognize and interact with identities directly. For example, an NFT marketplace can verify ownership of digital assets tied to your public key, or a DeFi protocol can grant access to services based on your wallet’s activity.

Conclusion
Identity on blockchain, and specifically on Solana, represents a shift from centralized control to self-sovereignty. Instead of relying on corporations or governments to define who you are online, you generate and own your identity through cryptographic keys. This identity is portable, secure, and verifiable across the entire Solana ecosystem.

An Overview of Wallets on the Solana Network and Their Use Cases

Hauwa Ibrahim — Mon, 27 Apr 2026 21:46:23 +0000

Day 5 of #100daysofsolana

Wallet are a means of authenticating an identity on blockchain apart from their other use of storing funds in them. It can be comparable to a google account which we use to sign in/up on different platforms on the internet

Over the past days I learnt about solana wallets and some of their types which includes - CLI wallets, Wallet extensions, mobile wallet.

CLI wallet: This is a wallet created on a computer terminal .
When is it used?
This is usually used in development i.e when writing script and testing a program
It has a shortfall, the private key is stored in a file on a computer which can be read by anyone who has access to the computer. Real money can't be stored in it.

Browser extension wallet: This encrypt private keys, add password layer to prevent unaauthorized access, approves or disapprove transactions whenever a site requests of it. This is safer than CLI wallet and allows for interaction with decentralised applications(dApps)

Mobile wallet: This has an additional layer of protection, it supports biometrics authentication(FaceId and fingerprint) alongside password. Real money can be stored on it.