DEV Community: Murtala Mudi

Pidgin English Can Now Find Your Spare Parts. Here Is How I Built That.

Murtala Mudi — Sat, 06 Jun 2026 15:04:09 +0000

I Started Building SpareIQ Months Ago and Never Finished It. Here Is What Happened When I Finally Did.

This is a submission for the GitHub Finish-Up-A-Thon Challenge

My dad was an auto mechanic and spare parts dealer for most of my childhood.

I watched customers walk into his shop every single day with the same problem. They needed a part but did not know what it was called. They would describe it by saying things like "the round rubber thing near the wheel that makes that sound" or "the metal piece that holds the side mirror." My dad always knew what they meant. But he was one person, and he could not always be there.

That image follows me for years.

When I started learning to code, I thought about building something for that problem. A platform for Nigerian auto parts shops where customers could search in the way they actually speak, not in the way an engineer would write a parts catalogue. I started it. I got a basic structure up. And then I stopped.

Life moved. I kept learning. The project sat there, half built, doing nothing.

The Finish-Up-A-Thon gave me a reason to go back.

What I Built

SpareIQ is an AI-powered spare parts inventory and finder platform built specifically for the Nigerian auto market.

The feature I am most proud of is the AI Part Finder. You open it and you type however you would naturally describe a part. In English or in Pidgin. Or in whatever words come to you. The AI identifies the technical name, categorises it, and searches the live inventory for matching results.

I typed "the thing wey dey stop my Toyota when I press the pedal" and it came back with Brake Pads.

Beyond the AI finder, SpareIQ has a public storefront with search and category filters, part detail pages, a protected shop owner dashboard, full inventory management with image uploads, and Firebase powering everything in real time.

🌐 Live site: https://spareiq.netlify.app
💻 GitHub: https://github.com/mudimurtala/spareiq

Demo

Here is a full walkthrough of SpareIQ in action:

If you want to try the AI finder yourself, go to spareiq.netlify.app and type:

"the thing wey dey stop my Toyota when I press the pedal"

Watch what happens.

The Comeback Story

When I came back to this project, I spent the first hour just clicking through it trying to understand what past-me had built.

Some things worked. The routing was there. Firebase was connected. Parts were showing on the page. But a lot of things were quietly broken in ways that would have embarrassed me if I had shown it to anyone.

The View Details button on every single part card did nothing. I first thought I could see soem errors and I isn't redirecting me to a wrong page, it just does nothing when I clicked on it. When I looked at the code, I found this sitting inside the button:

onClick={(e) => {
  e.preventDefault();
}}

A prompt I made earlier had added that to prevent some imagined double-click issue and in doing so had silently cancelled every navigation attempt. I removed the line and the whole thing started working.

The dashboard had a sidebar on the overview page. But the moment you clicked into Inventory Management or Add New Part, the sidebar disappeared completely. I were stranded on a page with no way back to the dashboard except the browser back button. I created a reusable DashboardLayout component and wrapped every dashboard page with it.

The hero search on the homepage would take you to the Parts page but your search term vanished the moment you got there. The Parts page had no idea what you had typed. I added a URL query parameter so the search term travels with you and pre-fills the results.

Those were the fixes.

Then came the things I added.

The homepage was too tall. You had to scroll before you even saw a single part. I reduced the hero padding and the featured parts grid jumped into view immediately.

I added a Browse by Category section between the hero and the featured parts. Clickable cards, one for each category: Engine, Brakes, Electrical, Suspension, Body Parts, Cooling System. Each one filters the parts page when clicked.

I added a Why SpareIQ section with three columns explaining what makes the platform different. And I built a proper footer with contact details, quick links, and the copyright line that makes any website feel finished.

Before this challenge: I had broken buttons, disappearing navigation, a homepage that hid its own content.

After the challenge: I have a deployed product I would actually show someone.

My Experience with GitHub Copilot

I want to be honest about how I used GitHub Copilot because I think the honest version is more useful than the polished version.

GitHub Copilot did not build SpareIQ. I did. But it was the difference between building something in five days and building something in five weeks.

The way it actually worked was this: I would come to the project knowing what I wanted to build. I had the architecture in my head, the feature requirement was clear, the user experience I wanted was decided. Then I would write a detailed prompt, sometimes paragraph length, explaining the exact file, the exact behaviour, the stack constraints, the edge cases. Copilot would generate the code. I would read it, test it, and decide if it was right.

That last step is the important one. There were times Copilot generated code that compiled perfectly and looked completely reasonable but was subtly wrong. The e.preventDefault() bug I mentioned was not something Copilot introduced during the Finish-Up-A-Thon. It was something added months earlier during the original build and I had not caught it because I did not read carefully enough.

The lesson I keep learning is that AI tools make me faster but they do not replace my understanding. If you cannot read the code and know whether it is right, you will miss the quiet bugs.

One moment that impressed me was when I gave Copilot a large prompt to implement the DashboardLayout component and wrap all the dashboard pages. It generated the code, ran the build, caught a TypeScript error it had introduced, fixed it, ran the build again, and only stopped when it passed. I watched that loop happen without me doing anything. That kind of self-correction used to take me hours of debugging.

The AI Finder itself was the most interesting part to build. The first model I tried returned quota errors. Copilot helped me swap the entire request structure to a different provider model cleanly and quickly. When the inventory matching was returning wrong results because it was matching on category alone, I described the scoring system I wanted in plain words and Copilot implemented keyword extraction with weighted scoring that made the matching accurate.

Working with GitHub Copilot on this project felt like having a very fast contractor who needs precise instructions and cannot always be trusted without supervision. When I gave it clear direction, the output was excellent. When I was vague, the output was generic. The quality of what it built was almost entirely determined by the quality of what I asked for.

What SpareIQ Is Built With

React 18
TypeScript
Tailwind CSS
Vite
React Router v6
TanStack Query
Firebase Auth and Firestore
Cloudinary for image hosting
OpenRouter API for AI model access
Netlify for deployment

One Last Thing

I am a self-taught developer from Nigeria. I studied Microbiology at university and started coding because I wanted to solve problems I actually understood.

SpareIQ came from watching my dad talk to customers who could not name the part they needed and thinking there should be a better way.

Finishing it felt like closing a loop that had been open for a long time.

If you have your own half-built thing sitting somewhere, I hope this is the nudge to go back to it.

I Spent My Time Building Tokens on Solana. What Got Me Surprised? Read This.

Murtala Mudi — Thu, 28 May 2026 04:06:07 +0000

I want to tell you something nobody told me before I started this.

Building tokens on Solana is not complicated. The CLI does most of the heavy lifting. You run a few commands, something appears on-chain, and you can verify it in a block explorer within seconds. That part is genuinely smooth.

What is not smooth is the moment you realize how differently Solana thinks about money, ownership, and rules compared to everything you have built in Web2. That mental shift is where the real learning lives.

This is my honest account of building tokens on Solana for the first time, covering everything from a basic mint to soulbound credentials that cannot be transferred. I am a web developer still learning. These are my notes from the trenches.

Starting point: creating a basic token

The first thing I learned is that every token on Solana has two separate things: a mint and a token account.

The mint is the factory definition. It says: this token exists, it has 6 decimal places, and this wallet has authority to create more of it. The token account is where actual tokens live. Your wallet cannot hold tokens directly. It holds token accounts, one per token type, each one like a separate pocket.

Creating a token is one command:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 6

That --program-id flag points at the Token Extensions Program, also called Token-2022. It is the newer, more powerful version of Solana's original token program. I used it from day one because it supports features the original program cannot do.

After creating the mint I had to create a token account and then mint supply into it:

spl-token create-account [MINT_ADDRESS]
spl-token mint [MINT_ADDRESS] 1000

Simple. But without metadata my token was just a random address. Nobody looking at it would know what it was.

The metadata moment

In Web2, if you launch an in-app currency you give it a name, a symbol, maybe a logo. You store that information in your database.

On Solana, with the Token Extensions Program, you can store metadata directly on the mint account itself. On-chain. No separate service, no external database.

spl-token initialize-metadata [MINT] "100DaysCoin" "HUNDO" "https://..."

One command and my token had a name and symbol visible to any wallet, any explorer, any app that looked it up. That felt significant. The token's identity is part of the token, not hosted somewhere that could go down or change.

Transfer fees without a backend

This is the one that genuinely stopped me for a moment.

In Web2, if you want to take a cut of every transaction on your platform you build middleware. You intercept transfers, calculate the fee, route it to your account, handle edge cases, write tests for the fee logic, and pray nothing breaks when someone sends an unusual amount.

On Solana you configure it once at mint creation:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 200 \
  --transfer-fee-maximum-fee 5000 \
  --enable-metadata \
  --decimals 9

Two hundred basis points is 2%. From that point on, every transfer of this token automatically withholds 2% in the recipient's token account. Not in my account. Withheld in theirs, but locked so only I can collect it.

When I transferred 100 tokens to a second wallet the recipient got 98. The other 2 sat withheld. Then I ran one command to collect them:

spl-token withdraw-withheld-tokens [MY_TOKEN_ACCOUNT] [RECIPIENT_TOKEN_ACCOUNT]

No backend. No payment processor. No middleware. The Token Extensions Program enforced the fee at the protocol level on every single transfer. I cannot think of an equivalent in Web2 that does not involve significant infrastructure.

The experiment I enjoyed most: making a token that cannot move

The last thing I built this week was a non-transferable token. The blockchain world calls these soulbound tokens.

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-non-transferable

I minted 10 tokens to my wallet then deliberately tried to send 5 to another wallet. The transaction failed:

Error: Non-transferable token

That error was the point. The Token Extensions Program rejected the transfer at the protocol level. Not an application rule that a clever developer could bypass. The program itself will not process the instruction.

What I found interesting is that burning still works. The holder can destroy their own tokens. They just cannot give them to anyone else. So it is not about trapping someone with something they do not want. It is about making credentials that prove something about a specific wallet.

Think about course completion certificates. Currently these live in databases that companies control. On Solana a non-transferable token could represent that certificate permanently, tied to the wallet that earned it, verifiable by anyone, controlled by nobody.

What actually surprised me

The thing that surprised me most was not a feature. It was a constraint.

Extensions must be added at mint creation. You cannot add a transfer fee to an existing token. You cannot make a transferable token non-transferable after the fact. The configuration is baked in permanently.

Coming from Web2 where you can alter a database schema or deploy a new version of an API this feels restrictive. But it is also what makes these tokens trustworthy. When someone receives a token with a 2% transfer fee they know that fee will always be 2%. Nobody can change the rules after the fact. The immutability is the feature.

That is the mental shift Solana keeps asking you to make. What feels like a limitation is often a design decision that creates trust without requiring anyone to trust a specific person or company.

Where I am headed

I have been doing the #100DaysOfSolana challenge with Major League Hacking. I am five weeks in. Next up is moving beyond tokens into actual programs and on-chain logic.

If you are a Web2 developer curious about Solana my honest advice is this: do not wait until you understand the theory. Build something small, watch it work, watch it fail, and let the confusion lead you to the understanding. The concepts will click faster through a terminal than through documentation.

See you in the next post.

100DaysOfSolana #Solana #buildinpublic

Solana's Account Model Explained By Someone Who Got Confused By It First

Murtala Mudi — Wed, 27 May 2026 02:47:08 +0000

Let me start with a confession.

When I first heard "everything on Solana is an account," I nodded like I understood. I did not understand. I just did not want to look confused.

It took me actually running commands in the terminal, seeing things break, reading error messages I did not expect, and sitting with the output until it clicked. That is what this post is about. Not the polished explanation. The actual journey.

Forget your database mental model first

Coming from Web2, my brain was wired to think in tables. You have a users table, a transactions table, maybe a products table. Each one has columns. Each row is a record. Data and code live completely separately.

Solana does not work like that.

On Solana, everything is an account. Your wallet is an account. A smart contract is an account. The token you hold is an account. The metadata of that token is an account. All of them. Every single thing on the network is described by the same five fields.

I know that sounds weird. Keep reading.

The five fields that describe everything

When I ran solana account against my own devnet wallet, here is what came back:

Public Key: CN9aDJfMzzQiR7mFGZCVbJHXKjdVAAiZJsEsmVTS3ZQo
Balance: 0.00158688 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 18446744073709551615

Let me break down what each of these actually means in plain terms:

Lamports (Balance): The SOL balance stored in the account. 1 SOL equals exactly one billion lamports. The network always works in lamports internally.

Data: A raw byte array. For a basic wallet this is zero bytes because wallets do not store custom data. For a smart contract account this contains compiled program code.

Owner: The program that has authority over this account. See that long string of ones? That is the System Program. It is Solana's root-level kernel. It owns every regular wallet on the network.

Executable: A simple true or false. If true, the bytes in the data field are treated as runnable program code. If false, it is just storage.

Rent Epoch: A legacy field from when Solana charged ongoing rent for storage. That system is deprecated now. For rent-exempt accounts it just shows a very large number. You can mostly ignore it.

The thing that actually broke my Web2 brain

Here is the part that tripped me up the most.

In Ethereum and in traditional backends, code and data are often coupled. A smart contract manages its own internal storage. You deploy the contract and the storage comes with it.

On Solana, programs are completely stateless.

The program account holds code. A separate data account holds state. They are two different accounts. The program owns the data account, meaning only that program can write to it. When you call a program, you explicitly pass in every account it will need to read from or write to during that transaction.

The analogy that finally made it click for me: think of a Solana program like a web server. The server runs code but it does not store your user photos inside its own binary. It reads from and writes to external storage. The program is the server. The data accounts are the storage.

This separation is also what makes Solana fast. Because you declare every account a transaction will touch upfront, validators know in advance which pieces of state are being used. Transactions that touch different accounts can run in parallel without stepping on each other.

The error that taught me more than any tutorial

I wanted to create an account manually with 100 bytes of storage. I found a command in some tutorial and ran it:

solana create-account ...

My terminal responded with:

error: The subcommand 'create-account' wasn't recognized
       Did you mean 'create-stake-account'?

Web3 tooling moves fast. Tutorials get stale. That is just the reality.

But the error pushed me to understand the actual underlying mechanic. An account on Solana does not exist until it holds lamports. Because validators store the entire network state in RAM for speed, you have to pay for the space you occupy. This deposit is called being rent-exempt.

I ran this to find out exactly how much 100 bytes would cost:

solana rent 100

The answer was 0.00158688 SOL. Then I funded the address directly:

solana transfer CN9aDJfMzzQiR7mFGZCVbJHXKjdVAAiZJsEsmVTS3ZQo 0.00158688 --allow-unfunded-recipient --url devnet

The transaction confirmed, the System Program recognized the incoming lamports, and the account came to life on the ledger. No special creation command needed. Just meeting the minimum balance requirement.

That one broken command taught me more about how Solana actually works than three hours of reading documentation did.

What I am carrying forward from this

Just three things:

Programs and data are always separate. Get comfortable with that. It is very different from how most Web2 backends are structured but once it clicks it makes sense.

Space is a financial decision. When you build on Solana you cannot just add columns to a database and call it a day. Every byte of on-chain storage costs real tokens. You think carefully about your data layout before you deploy.

When CLI commands break, drop to the fundamentals. Do not spend an hour looking for the right command. Understand what you are actually trying to do at the network level, then find the simplest path to accomplish it.

I am still learning. Some days the terminal cooperates and some days it absolutely does not. But I understand a lot more about what is happening under the hood than I did two weeks ago.

If you are also on this journey and something I said clicked or confused you, say so in the comments. I read them.

100DaysOfSolana #Solana #Web3 #beginners

100 Days of Solana — Day 20: I Tried to Break Solana and It Charged Me for It

Murtala Mudi — Tue, 26 May 2026 11:53:01 +0000

Let me tell you about the moment Solana surprised me.

I was building a transfer script this week. Nothing fancy, just a tool that moves SOL from one wallet to another programmatically. I wanted to see what happens when a transaction fails on-chain. Not a simulation. Not a dry run. An actual failed transaction sent straight to the network.

So I deliberately tried to transfer 500 SOL from a wallet holding about 5.5 SOL.

Obviously it was going to fail. That was the point.

What I did not expect was the bill.

Failure is not free on Solana

In Web2, when a database transaction rolls back, nothing happens to your infrastructure costs in that moment. The operation failed, the state did not change, you try again. No charge for the failed attempt.

On Solana, validators are real machines run by real people. When you send a transaction, those machines do actual work before they even get to decide if it succeeds. They ingest it, parse the signatures, verify the accounts, check the bounds. That work costs compute resources.

So they get paid. Even when your transaction fails.

Here is exactly what I saw in the terminal after my intentionally broken transfer hit the network:

Transaction executed in slot 465034224:
  Recent Blockhash: ENvhACYop3KqzHZVwcGxmKTCKCvpQtnUotTUiU4K3B4c
  Account 0: srw- cRrbhRLCyJcWV6Tmzti4v7aXXXSaRVckTGwaDCspNZM (fee payer)

  Instruction 0
    Program: 11111111111111111111111111111111
    Transfer { lamports: 500000000000 }

  Status: Error processing Instruction 0: custom program error: 0x1
    Fee: ◎0.000005
    Account 0 balance: ◎5.537975 -> ◎5.537970

  Log Messages:
    Program 11111111111111111111111111111111 invoke [1]
    Transfer: insufficient lamports 5537970000, need 500000000000
    Program 11111111111111111111111111111111 failed: custom program error: 0x1

Look at that balance line. 5.537975 -> 5.537970. The transfer did not go through. But the wallet still lost 0.000005 SOL.

Small amount. Big lesson.

What that error code actually means

The runtime returned custom program error: 0x1. That is not a random code. In Solana's System Program source code, 0x1 maps directly to InsufficientFundsForTransfer. Every error has a specific hex identity. When something breaks, you can trace it back to exactly what went wrong at the program level.

This is actually useful once you get used to it. Error messages in Web2 backends can be vague. Here everything is explicit and traceable.

The pipe pattern changed how I think about building transactions

Something else shifted this week on the code side.

If you read older Solana tutorials, you will see transactions built like this: create an object, mutate it, add instructions one by one. It is the old way and it works, but the modern @solana/kit does it differently.

Everything is a pipeline. You start with a base message and pass it through a series of functions, each one adding something to it:

const transactionMessage = pipe(
  createTransactionMessage({ version: 0 }),
  (tx) => setTransactionMessageFeePayerSigner(signer, tx),
  (tx) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),
  (tx) => appendTransactionMessageInstruction(
    getTransferSolInstruction({
      source: signer,
      destination: destinationAddress,
      amount: lamportAmount,
    }),
    tx
  )
);

Each step is pure. Nothing mutates. You can read it top to bottom and understand exactly what the transaction contains before it ever touches the network. Coming from JavaScript where we mutate state constantly, this took a little getting used to. But once it clicks it feels cleaner than the old approach.

The 1,232 byte limit is real and it forces good habits

One more thing worth knowing. Every Solana transaction has to fit inside 1,232 bytes. That is the network packet size limit and it is not flexible.

In Web2 you can send massive JSON payloads without thinking about it. On Solana you have to be intentional about how many accounts you include, how you pack your instructions, what you actually need versus what you are dragging along unnecessarily.

It is a constraint that makes you think more carefully about what you are building. I have started to appreciate that.

What I am walking away with from this week

Three things:

Always simulate before you send. The SDK has pre-flight simulation built in. Use it so your users are not paying fees for errors you could have caught locally.

Errors are traceable. Hex codes, program logs, account balance diffs. Everything is on-chain and readable. The transparency is actually one of the best parts of building here.

The functional pipe pattern is worth learning. It makes your transaction construction readable and predictable in a way that feels very different from the object mutation style.

Twenty days in. Still learning. Still occasionally breaking things on devnet.

But I understand why things break now, and that is progress.

100DaysOfSolana #Solana #Web3 #buildinpublic

Part of my ongoing #100DaysOfSolana journey with Major League Hacking.

100 Days of Solana — Week 2 Reflection: How Solana Broke My Web2 Brain (In a Good Way)

Murtala Mudi — Tue, 26 May 2026 06:29:45 +0000

I want to be honest with you.

When I signed up for the 100 Days of Solana challenge, I thought it was going to be like learning a new JavaScript framework. Same concepts, different syntax. I would pick it up in a few days and move on.

I was wrong.

Two weeks in, and Solana has genuinely changed how I think about databases, storage, and what it even means to "store data." I am still a student. I am still figuring things out. But some things clicked this week in a way that I want to write down before they fade, and maybe help someone else who is starting from the same place I was.

When things started to make sense: Accounts

The biggest mental shift for me was understanding that on Solana, everything is an account.

Coming from Web2, that sentence sounds normal until you realize what it actually means. I was expecting something like a database with tables: one table for users, one for tokens, one for transactions. That is not how it works at all.

On Solana, your wallet is an account. A smart contract is an account. A token is an account. They all use the same underlying structure. The thing that tells them apart is a few fields: whether the account is executable (code or data?) and who the owner is (which program controls it?).

To see this for real, I used the Solana CLI to inspect two accounts side by side:

solana account cRrbhRLCyJcWV6Tmzti4v7aXXXSaRVckTGwaDCspNZM

My wallet came back with:

Owner: 11111111111111111111111111111111 (the System Program, Solana's root engine)
Executable: false
Length: 0 bytes

Just a record tracking a balance. No custom fields. No tables. Then I queried a live smart contract and the properties flipped completely. Executable became true, the owner changed to the BPF Loader, and instead of a balance it returned raw binary data representing compiled program code.

Same account structure. Totally different purpose. That is when the "global public database" idea stopped being a metaphor and became something I actually understood.

Switching environments is just one URL change

In Web2, moving from a staging environment to production is serious work. You update environment variables, run migrations, pray nothing breaks. It is a whole process.

On Solana? You change one URL.

I wrote a script using @solana/kit that queried the same program address on both Devnet and Mainnet at the same time:

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

const devnetRpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));
const mainnetRpc = createSolanaRpc(mainnet("https://api.mainnet-beta.solana.com"));

The output showed the same address holding completely different balances and transaction histories on two separate networks. Same code. Same API calls. But Devnet and Mainnet are isolated ledgers that have never shared state.

This is actually cleaner than most Web2 staging setups I have seen. The logic does not change at all. Only the data source does.

The thing that surprised me most: you pay rent for RAM

This one genuinely caught me off guard.

In cloud computing, you pay for storage on a hard drive. On Solana, validators store all active account data in RAM, because RAM is what makes the network fast. And RAM is expensive. So the network charges a deposit per byte of data you store.

It is called rent, and it is refundable. If you close an account later, you get 100% of that deposit back into your wallet.

I ran these two commands to see the difference:

solana rent 0
solana rent 1000

Watching the lamport cost scale up linearly per byte made storage costs feel very real and very predictable in a way that cloud bills never do. And the fact that you can reclaim it? That is a design pattern I have not seen anywhere in traditional backend development.

What I am taking into Week 3

I will not pretend everything is smooth. There are still moments where I open the terminal and something fails and I have to go read the docs again. That is just part of it.

But I am genuinely curious now in a way I was not two weeks ago. How does Solana maintain atomicity when multiple accounts are being updated in one transaction? How do you structure a transaction to avoid bottlenecks when you have a lot of data to write?

These are questions I could not have even asked on Day 1. The fact that I am asking them now means something is working.

If you are also doing this challenge or thinking about starting, do not wait until you feel ready. The understanding builds as you go. Week 2 Mudi knows things that Week 0 Mudi had no framework to even imagine.

See you on Day 14.

This post is part of my #100DaysOfSolana journey with Major League Hacking. I write about what I learn each week, including the confusing parts.

How Amazing I felt After Sending SOL from my phone to my local Ubuntu terminal

Murtala Mudi — Mon, 25 May 2026 14:38:34 +0000

Hi everyone, I moved to Day 7 of the 100 days of Solana challenge today and I can say It has been very interesting to go through all these experiments.

I did something really cool. I tried sending devnet SOL from the normal Phantom app I downloaded on my mobile phone straight to the CLI wallet on my local computer's terminal. To be honest, I found it so fascinating that I even did it twice! I just wanted to confirm and see exactly how things work in real-time, and it was amazing to watch the command line balance increase the moment I sent it from my phone.

While doing this, I noticed a big difference in how these wallets handle security and convenience:

The Mobile Wallet: I noticed that the app on my phone is not that convenient for quick back-and-forth work. Even without minimizing it or moving out of the app, after some seconds or minutes, it just asks me to confirm my fingerprint again. The moment I move out of the app to check something on my browser and come back, it must require that I initiate my fingerprint again. Even though this is not that convenient, I think it is the most secure way to safeguard my digital assets so that they can be accessed by only me and not anyone else.
The CLI Wallet: On the other hand, the one on my local computer is just the most convenient. All I need is to type in the command to do something, either to show the remaining balance or transfer something, and it just works instantly without asking for fingerprints every second.

For my personal use, I will definitely choose the one on my phone because I want my digital assets to be completely secured. But for development and practicing code, the CLI is just the best because it is fast.

It feels great to see how these different wallets connect on the same network. I am excited to finish this first week and see what is required of me in the next steps!

Let me know how your first week went!

Dear Web2 Developer... Solana is here calling

Murtala Mudi — Mon, 25 May 2026 13:15:21 +0000

As web developers, we know exactly how user accounts work. When a user signs up for an application, we create a users table in a database. We hash their password, assign them a unique user_id, and manage their session status using tokens or cookies.

In this traditional Web2 setup, identity is entirely fragmented. A user is one row in a GitHub database, another row in a LinkedIn database, and another row in their banking application. None of these applications inherently speak to each other, and more importantly, the user doesn't actually own their identity, the company hosting the database actually does. If an admin deletes that database row, that identity is gone.

As I've been jumping into the first week of the 100 Days of Solana challenge, the biggest mental shift wasn't learning a new framework; it was redefining what "identity" actually means on a blockchain.

Check how identity works on Solana below, I explained it through concepts we're already familiar with in our everyday life.

The Model: You Already Use Web3 Identity (I'm assume this to be true)

You connecting to a remote server or you securely pushing code to GitHub using terminal commands, knowingly or unknowingly, you've already used the core engine of Web3 identity: SSH Keypairs.

When setting up SSH, you run a command locally to generate a keypair. This gives you:

A Public Key that you safely share with GitHub or a remote Linux server.
A Private Key that stays hidden inside your machine's local configuration files.

When you push code, your machine uses your private key to cryptographically "sign" the request. The server uses your public key to verify that the signature is valid.

Solana works exactly the same way. On-chain identity starts with an Ed25519 cryptographic keypair. There are no centralized registration forms, no email verifications, and no usernames. The entire network acts as a single, global ledger, and your public key is your universal identity across every single application built on top of it.

Breakdown of a Solana Address

In Web2, your username might be dev_muritala. On Solana, your identity looks more like this: 4zMMC9srtxt2nvbBt3wjfBBs71A7HK8gZrybFmZuxyJu.

This string is a 32-byte public key encoded in Base58. Cryptographers deliberately chose Base58 for blockchain addresses because it optimizes for human scannability by completely removing visually ambiguous characters. You won't find the number 0, uppercase O, uppercase I, or lowercase l in a Solana address. This prevents catastrophic copy-paste mistakes when developers or users are routing assets or interacting with software on-chain.

Custody: No Password Reset Flows

The shift in architectural control changes everything when transitioning from Web2 to Web3.

In Web2, if a user loses their credentials, they click a "Forgot Password" link. An automated backend system sends an email link, verifies their response, and updates the database row. The platform retains ultimate authority over the account data.

On Solana, there is no corporate admin panel, no support desk, and no password reset flow. Identity is completely non-custodial.

If your private key lives as a plaintext file on your local development machine (like a standard CLI development environment), it is highly scriptable but vulnerable if the machine compromises.
If your private key is encrypted inside a browser extension wallet (like Phantom), it introduces a secure confirmation popup layer before any transaction can execute.
If it is guarded behind mobile OS secure sandboxes protected by biometric fingerprint scanners, it trades off rapid script deployment for superior physical protection.

But regardless of the storage medium, whoever holds the private key owns the identity. If you lose the key material or your recovery seed phrase, the identity is mathematically unrecoverable.

What This Identity Enables

This cryptographic setup does more than just replace the traditional username/password paradigm. Because your identity is recognized globally by the entire Solana runtime, it acts as a universal passport.

With a single public key, you can simultaneously hold tokens, execute custom code routines, vote on platform governance protocols, and build a verifiable developer reputation across hundreds of independent ecosystem tools. You don't need to request access or integrate third-party OAuth providers. You simply sign a permission request with your private key, and you are instantly authenticated.

Conclusion

Transitioning into Web3 as a developer requires looking past the surface level of tools and looking directly at the architectural foundation. Identity on Solana isn't a collection of accounts granted to you by corporate servers, it is a sovereign, mathematical certainty that you control completely from your own local workspace.

If you are a developer looking to build systems where users have true ownership of their data and actions, understanding the mechanics of the cryptographic keypair is your first real step.