DEV Community: Murtala Mudi

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.