DEV Community: Peter Okoh

From Web2 Complexity to On-Chain Simplicity

Peter Okoh — Fri, 22 May 2026 10:24:23 +0000

Today’s Solana learning unlocked a new level for me.

I just created a token where the transfer fee is enforced directly by the Token-2022 Program itself.

Not by some backend script.
Not by middleware.
Not by an API quietly calculating charges behind the scenes.

The logic lives on-chain.

That means every valid transfer follows the same fee rules automatically, and if the expected fee is wrong, the transaction simply fails.

What really amazed me is how much complexity this removes.

In Web2, implementing transaction fees usually means building payment logic, handling edge cases, tracking deductions, worrying about rounding errors, and making sure nobody bypasses the system.

But here, the fee configuration is part of the mint itself.
Once set, the program handles the rest.

Even the withheld fees are transparent on-chain and can later be withdrawn by the designated authority. Everything is visible. Everything is verifiable.

The more I learn about Solana, the more I realise blockchain development is not just about “sending tokens".

It’s about building systems where trust is enforced by code and protocol rules, not by hidden backend logic.

And honestly, the fact that all of this only took a few CLI commands still blows my mind.

Day31

My Experience Building My First Token And Having it Exist On-Chain.

Peter Okoh — Thu, 21 May 2026 20:18:07 +0000

There’s something quietly satisfying about seeing a token you built from scratch exist on-chain.

Not just a random mint address…
But a token with its own name, symbol, metadata, supply, and even transfers between wallets.

Today made Solana feel a lot more real to me.

What fascinates me most is how blockchain simplifies things that would normally require a full backend system in Web2.

In a traditional app, you would create database tables for balances, build APIs for transfers, manage metadata, and maintain servers to keep everything running.

But on Solana, the protocol already provides the structure.

The mint becomes the definition of the currency.
The associated token account becomes the balance record.
And the transfer instruction becomes the movement of value between users.

Except this time, everything is transparent and verifiable on-chain.

I also explored Token Extensions metadata today, and I love the idea of storing metadata directly inside the mint account itself. Fewer moving parts, fewer accounts, lower costs, and a cleaner design overall.

Still learning.
Still experimenting.
But moments like this make me genuinely excited for what’s ahead in the Solana ecosystem.

Day30

#100DaysOfSolana Day29: My Experience Generating Token On Solana Devnet

Peter Okoh — Wed, 20 May 2026 14:12:25 +0000

Yesterday felt different.

I just created my first token on Solana Devnet using the SPL Token Program… and I can’t fully explain the excitement that came with seeing it live on-chain.

Not a fake database entry.
Not something sitting quietly in a backend server.

An actual token hosted on the blockchain that anyone can verify.

One thing that really stood out to me is how much Solana abstracts away the hard parts. In Web2, building something like this would mean creating database schemas, APIs, handling double-spending logic, server maintenance, and a lot more stress.

But here?
The SPL Token Program already provides a secure and audited foundation to build on.

I also started understanding the structure behind it all:
• The Mint account acts as the source of truth for the token
• The Token account stores individual balances
• And every wallet needs its own token account before receiving tokens

At first, it felt unusual.
Now, it’s starting to make sense.

This may look like a small step, but for me, it feels like the beginning of something much bigger.

Excited to keep building, keep breaking things, and keep learning deeper layers of Solana.

WEEK 4 #100DaysOfSolana: LAMPORTS IN SOLANA

Peter Okoh — Wed, 20 May 2026 07:07:19 +0000

When I first started digging into Solana accounts, those fields,lamports, owner, data, executable,looked like low-level noise.

But they’re actually the real “anatomy” of everything on-chain.

lamports is simply the balance of an account. Not abstract value, actual rent-paying power that keeps the account alive on the network.

owner tells you "who controls the rules." It’s not about possession, it’s about which program has the authority to read, write, and mutate that account’s state.

data is where the real story lives. It’s the storage layer—custom bytes that programs interpret however they were designed to. Same field, different meaning depending on the program behind it.

And then there’s executable. This one flips the perspective: is this account just data, or is it a program that can actually run instructions?

Once these clicked for me, Solana stopped feeling like “magic transactions” and started looking like a structured system where every account has a job.

And honestly, that shift changes everything.

Week 4 #100DaysOfSolana: My Explorer

Peter Okoh — Mon, 18 May 2026 11:27:33 +0000

Spent some time today exploring transaction history on Solana Explorer, and it’s honestly one of the easiest ways to understand what’s happening under the hood on-chain.

In this screenshot, I’m looking at the transaction history of a Solana account on devnet. You can see successful and failed transactions, block numbers, timestamps, and raw transaction data all in one place. Seeing both successful and failed transactions side-by-side makes debugging feel much more practical.

One thing that stood out to me was how transparent Solana transactions are. I didn’t realise how much detail the explorer exposes, from programme ownership down to transaction-level history and execution results. It really helps connect the theory of “everything is an account” to what’s actually happening on-chain.

I used the Solana Explorer for this, and I’d definitely recommend it, especially for beginners learning how accounts, programs, and transactions interact. It makes the network feel far less abstract.

100daysofsolana

Day28

Week 4: #100DaysOfSolana; Account Model

Peter Okoh — Mon, 18 May 2026 10:34:22 +0000

On Solana, everything is an account. There’s no separation between wallet accounts, smart contracts, or data storage. They all live in one unified system. Every account is just a key-value entry where the key is a 32-byte address and the value is the account itself. I like to think of it as a giant filesystem where every file is an account.

Every Solana account also shares the same structure. It always has five fields: lamports (the balance in SOL, where 1 SOL = 1 billion lamports), data (a raw byte array for storing state), owner (the program that controls the account), executable (a flag that tells you if it’s a program), and rent epoch (mostly deprecated and usually maxed out now).

The ownership rule is also very strict but simple. Only the owner program can modify an account’s data or deduct its lamports. However, anyone can send lamports into an account as long as it’s writable. This makes the security model very predictable because control is tied to ownership, not identity.

One of the biggest surprises for me was that programs don’t store their own state. On Solana, programs are completely stateless. The program is just logic, while state lives in separate data accounts. So instead of a smart contract holding everything internally, it behaves more like a backend server that reads and writes to a database.

Another important concept is rent exemption. Every account must hold a minimum amount of lamports based on its data size to stay alive on-chain. If it meets that threshold, it becomes “rent-exempt” and won’t be deleted. This can be gotten using:

To make sense of it all, I like using a simple analogy: Solana is like a filesystem. Each account is a file with metadata (owner, permissions, size) and content (data). Programs are executable files, data accounts are documents, and the system program acts like the operating system that manages everything.

Once this model clicks, Solana stops feeling abstract. Transactions start to look like structured file operations, and the entire system becomes much easier to reason about.

Solana is making more sense to me now.

100DaysOfSolana

Day27

WEEK 3 #100DAYSOFSOLANA: SHARING MY TOOL AND OUTPUT

Peter Okoh — Mon, 11 May 2026 11:03:24 +0000

When I first started learning Solana, transactions felt like magic.

You click "Send", wait a few seconds, and somehow value moves across a decentralised network. But after spending time building and debugging transactions myself, I realised that every Solana transaction has a very clear structure underneath it.

And honestly, understanding that structure made blockchain feel far less mysterious.

A transaction is more than “sending crypto”

Coming from Web2, I initially compared a Solana transaction to an API request.

You send data somewhere, something processes it, and the system changes state.

That analogy helps at first, but it breaks pretty quickly.

A Solana transaction is closer to a signed package of instructions that the network verifies before allowing any state change to happen. It’s atomic too, meaning either everything succeeds or nothing does, similar to a database transaction.

But unlike a normal API request, Solana transactions require cryptographic signatures and expire after a short period of time.

That was one of the first things that surprised me.

The four parts that finally made things click

Signatures: Proof of authorization

The signature is what proves that the transaction was approved by the owner of the wallet.

Without it, the network rejects the transaction completely.

It reminded me a bit of authentication tokens in Web2, except this is cryptographic proof instead of session-based trust.

When I used the Solana CLI to send SOL between wallets, I was unknowingly generating signatures every single time.

solana transfer 0.01 --allow-unfunded-recipient

At first, this just felt like a command.

Later, I realised I was actually signing an instruction with my private key and asking the network to verify it.

That perspective changed everything for me.

Instructions: The actual action being requested

Instructions are the real “what should happen” part of the transaction.

For example:

Transfer SOL
Create an account
Interact with a programme.
Mint a token

A single transaction can even contain multiple instructions bundled together.

That was unexpected for me because I originally assumed one transaction always meant one action.

But on Solana, a transaction can coordinate several operations at once.

Accounts: The data being read or modified

This was probably the biggest mindset shift.

In Web2, I’m used to thinking in terms of databases, tables, and backend-controlled state.

On Solana, everything revolves around accounts.

Transactions specify which accounts they want to interact with, whether those accounts are:

being modified
read from
signed by
or owned by a program

The network checks permissions before allowing anything to happen.

That level of explicitness felt uncomfortable at first, but it also made the system feel transparent.

Nothing is hidden.

Recent blockhash: A built-in expiration timer

This part confused me initially.

Why does a transaction need a recent blockhash?

Then it clicked: it prevents old transactions from being replayed forever.

A recent blockhash acts like a freshness check. If the transaction takes too long to process, it expires and becomes invalid.

In Web2, API requests usually don’t “expire” because of network state in this way.

That difference really showed me how blockchain systems think differently about trust and validation.

The biggest lesson for me is that a Solana transaction is not just “sending crypto".

It’s a structured, signed request for state changes on a public network.

Once I started understanding signatures, instructions, accounts, and recent blockhashes, transactions stopped feeling like magic and started feeling like systems engineering.

And that’s when Solana really began to make sense to me.

solana #100DaysOfSolana

Week 2 #100DaysOfSolana: Transactions

Peter Okoh — Mon, 11 May 2026 09:37:54 +0000

One thing Solana transactions taught me: blockchain feels very different when you actually debug it.

Coming from Web2, I initially thought a Solana transaction would feel similar to making an API request. You send data, the server processes it, and you get a response back.

But after building and debugging transactions myself, I realised that comparison only goes so far.

A Solana transaction is more like packaging a set of instructions, signing them with your wallet, and asking the network to agree on a state change. And the interesting part? Everything inside that transaction matters: accounts, signatures, permissions, fees, and even the exact order of instructions.

What really changed my perspective were the failed transactions.

In Web2, if an API call fails, you usually retry or check your backend logs. On Solana, failed transactions forced me to think differently. Sometimes the wrong signer was provided. Sometimes an account didn’t have enough SOL. Sometimes the instruction data itself was incorrect. The network is strict, and honestly, that strictness taught me a lot.

The biggest mindset shift for me has been understanding atomic state changes. Either the whole transaction succeeds, or none of it does. There’s no partial update or “we’ll fix it later in the database.” That level of consistency is powerful.

I’m still learning, but working directly with transactions has made blockchain feel less like hype and more like a completely different approach to computing and ownership.

solana #100DaysOfSolana

Sending Value Across A Decentralized Network Using Solana CLI

Peter Okoh — Wed, 06 May 2026 09:18:33 +0000

Today I did something simple, but it felt different.

I sent value across a decentralised network using the Solana CLI. No app interface, no “send” button, just a command in the terminal and a wallet address.

At first, it felt a bit raw. You’re typing commands, working with public keys, and trusting that everything is correct. But then it clicks… this isn’t just a transfer; it’s a signed instruction being verified by a global network.

No bank. No middleman. Just math and consensus.

What I found interesting is how direct it is. You see your balance, you send SOL, and you verify it, all from the terminal. It’s simple but also powerful.

It made me realise that behind every polished wallet app is this exact process, just abstracted away.

Still learning, but moments like this make the whole "decentralised" idea feel real.

100DaysOfSolana

Tracking on Solana explorer:

Week 2 of #100DaysOf Solana: Understand Transaction Anatomy

Peter Okoh — Tue, 05 May 2026 13:57:43 +0000

Not just clicking “send” and moving on, I actually looked under the hood.

I broke it down into signatures, instructions, accounts, and the exact data being passed. And honestly, it changed how I see blockchain completely.

What used to feel like a black box now feels structured and intentional. Every transaction is just a set of instructions, signed and verified by the network. No hidden logic. No backend magic.

It’s a bit uncomfortable at first because you’re closer to the raw data than in Web2, but that’s where the clarity comes from.

Still connecting all the dots, but one thing is clear: understanding what’s really happening behind a transaction makes everything else easier to grasp.

This is where things are starting to click.

100DaysOfSolana

Week 2 of #100DaysOfSolana: My Early Experience With Solana

Peter Okoh — Tue, 05 May 2026 12:29:40 +0000

Coming into Solana, I honestly expected blockchain data to feel abstract and complicated, like something hidden behind layers of cryptography that would be hard to reason about.

In my head, I thought it would look nothing like the databases I was used to in Web2. But the reality surprised me. Once I started working with accounts and RPC calls, it began to feel less like “mystery tech” and more like a different kind of database, just one that’s public, distributed, and stricter about how data is accessed and modified.

The biggest “click” moment for me was realising that Solana is basically a public database where everything revolves around accounts. Instead of tables and rows, you have accounts and programs. Instead of backend logic controlling access, the network enforces rules through signatures and ownership. That shift, from “my server controls everything” to “the network enforces everything", really changed how I think about building applications.

One thing that surprised me was how direct RPC calls are. In Web2, I’m used to clean APIs that return structured JSON designed for my app. With Solana, you’re closer to the raw data.

You fetch account info, and it’s on you (or your program) to understand what those bytes mean. It’s powerful, but also a bit uncomfortable at first because there’s less abstraction.

At the same time, it made me appreciate how transparent everything is. Reading on-chain data feels like querying a system where nothing is hidden. There’s no “private backend” doing magic behind the scenes. What you see is what exists. That’s very different from traditional APIs where you only get what the server decides to expose.

That said, I’m still wrapping my head around a few things. Program-Derived Addresses (PDAs) are one. I understand the idea, but I haven’t fully internalised when and why to use them.

I also want to get more comfortable with structuring account data and designing programs that manage state properly.

Overall, this has been a mindset shift more than anything else. I’m not just learning new tools; I’m learning a new way to think about data, identity, and ownership. And I’m starting to see why that matters.

100DaysOfSolana

Week 2 of #100DaysofSolana: Comparison Between Traditional Databases vs Solana Accounts

Peter Okoh — Tue, 05 May 2026 10:12:47 +0000

It was a beautiful thing comparing traditional databases and Solana accounts.

Below is a comparison table showing how they both work.