DEV Community: Peter Okoh

Day 76 #100daysofsolana: The CPI Mental Model I Wish I Had on Day 71

Peter Okoh — Fri, 24 Jul 2026 12:08:26 +0000

When I started learning Solana, Cross-Program Invocation (CPI) sounded far more complicated than it actually is.

I kept seeing CpiContext, invoke_signed, program IDs, account structs, and signer seeds everywhere. I could copy the examples, but if someone had asked me what was really happening under the hood, I probably wouldn't have had a good answer.

A few days later, after building a vault program, making one program call another, and intentionally breaking my own code just to understand the errors, everything finally clicked.

If I could go back to Day 71 and explain CPI to myself in one sentence, it would be this:

A CPI is just one Solana program asking another program to do some work, but it must bring the right program, the right accounts, and the right signer.

That simple idea made everything else easier to understand.

The mental model that finally made sense

Coming from Web2, I started thinking of a CPI like calling a function from another module.

Except on Solana, you can't just call the function.

You have to arrive with three things:

The program you want to call (identified by its Program ID).
Every account that program expects.
Who has the authority to approve the action.

Miss any one of those, and the runtime immediately complains.

That's really all a CpiContext is doing.

It packages those three pieces together before handing execution over to another program.

Once I stopped seeing CpiContext as some mysterious Anchor feature and started seeing it as a container for "who, what, and with what authority," the code became much easier to read.

A real example from my project

One of the exercises I built this week was a simple program that calls another program to increment a counter.

The handler was surprisingly small:

pub fn bump(ctx: Context<Bump>) -> Result<()> {
    let cpi_ctx = CpiContext::new(
        ctx.accounts.counter_program.key(),
        compose_lab::cpi::accounts::Increment {
            tally: ctx.accounts.tally.to_account_info(),
        },
    );

    compose_lab::cpi::increment(cpi_ctx)?;

    Ok(())
}

There isn't much happening here.

The caller simply says:

"Here's the program I want to call."
"Here's the account it needs."
"Go execute its increment instruction."

Earlier in the week, I also built a vault where a PDA signed on behalf of the program.

That was another moment where things finally clicked.

A PDA doesn't have a private key sitting somewhere waiting to sign a transaction.

Instead, the runtime recomputes the PDA using the same seeds and bump your program provides. If they match the PDA's address, the runtime treats that PDA as an authorized signer.

That made invoke_signed() feel a lot less magical.

What tripped me up

One of the best parts of this week's challenge was intentionally breaking working code.

I changed the PDA seeds.

I changed account constraints.

I even pointed a CPI at the System Program instead of my own program.

Each failure taught me something different.

One error I saw was:

Error Code: ConstraintSeeds.
Error Message: A seeds constraint was violated.

At first glance it looked intimidating.

But after slowing down and reading it, the message was actually telling me exactly what was wrong.

The PDA the caller passed didn't match the PDA the callee expected.

Later, I intentionally pointed my CPI to the System Program and got:

Program 11111111111111111111111111111111 failed:
invalid instruction data

That wasn't because my instruction was bad.

It was because I had sent perfectly valid instruction data to the wrong program.

Once I understood what each error was trying to tell me, debugging became much less frustrating.

Instead of random red text, the logs started feeling like clues.

My biggest takeaway

Looking back, CPI wasn't the hard part.

The hard part was trying to understand the code before I understood the mental model.

Once I realized every CPI comes down to the program, the accounts, and the signer, everything else started fitting together.

Even the errors became useful.

That's probably the biggest lesson I've learned so far in this Solana journey.

100daysofsolana

Day 69 #100daysofsolana: What a Week of Building on Solana Taught Me About Program Derived Addresses (PDAs)

Peter Okoh — Wed, 22 Jul 2026 20:26:36 +0000

When I first heard about Program Derived Addresses (PDAs), they sounded like one of those Solana concepts that everyone claims are simple until you actually have to use them. After spending the past week building a counter program with Anchor, breaking things on purpose, fixing them, and watching transactions fail for reasons I didn't understand at first, I can finally say I have a mental model that makes sense.

If you're coming from a Web2 background like I am, I hope this saves you a few hours of confusion.

Why do PDAs even exist?

One thing I learned early is that Solana programs don't store state the way a traditional backend application does. If your program needs to remember something, whether it's a user's profile, a game score, a counter, or a configuration, it needs a predictable account where that data lives.

That's exactly what a PDA gives you.

Think of it like a database primary key that can always be computed again. Instead of storing an address somewhere and looking it up later, your program derives it whenever it needs it.

The difference is that this address isn't random. It's derived from your program's seeds and your program ID, meaning the same inputs will always produce the same PDA.

The mental model that finally clicked

The analogy that helped me most was this:

Imagine a users table in a database.

Instead of looking up a row using an auto-increment ID, imagine you could always calculate the row's primary key from something like:

the application
the user's wallet address
a fixed prefix

That's basically what PDAs feel like.

Except there isn't actually a database.

The Solana account model is the storage layer, and PDAs are deterministic addresses that your program can always derive whenever it needs them.

Another important thing I learned is that deriving a PDA doesn't automatically create an account.

You can derive thousands of PDAs that don't exist yet. An account only comes into existence after your program initializes it.

Breaking down my own PDA

This is the pattern I used in my counter program.

#[account(
    init,
    payer = user,
    space = 8 + Counter::INIT_SPACE,
    seeds = [b"counter", user.key().as_ref()],
    bump
)]
pub counter: Account<'info, Counter>,

Here's what each piece does.

b"counter" is a static seed that identifies what kind of PDA this is.
user.key().as_ref() makes the PDA unique for each wallet.
seeds are combined with the program ID to derive the address.
bump is the extra byte Anchor finds to make sure the resulting address falls off the Ed25519 curve.

That last part confused me for a while.

The bump isn't magic. Anchor simply tries different bump values until it finds one that produces a valid PDA. Once it finds it, that's the canonical bump you should keep using.

Why your seeds matter

One of my biggest lessons came from intentionally changing my seeds and watching what happened.

Using:

seeds = [b"counter", user.key().as_ref()]

gave every wallet its own counter.

Changing it to:

seeds = [b"counter"]

meant everyone derived exactly the same PDA.

Neither approach is wrong.

It depends entirely on what you're building.

A global configuration account? A shared PDA is perfect.

A personal counter for every user?

A shared PDA becomes a disaster because everyone writes to the same account.

That experiment made the purpose of seeds much clearer than any documentation I had read.

What the bump actually buys you

The bump exists because not every derived address can safely become a PDA.

Anchor searches for the canonical bump value that works and stores it for you when you write:

bump

Later instructions can simply reuse the stored bump instead of recalculating it every time.

It's a small optimization, but it's also cleaner and less error-prone.

The lifecycle of a PDA

Over the past week, I noticed that every PDA in my project followed the same lifecycle.

Derive the PDA from seeds.
Initialize the account with init.
Read or update its data whenever needed.
Close the account when it's no longer useful.

Closing a PDA was another interesting lesson.

Coming from Web2, I kept thinking of it as deleting a database row.

It isn't.

Closing an account transfers its rent back to a recipient, clears the data, and marks the account for cleanup once the transaction finishes.

It's a subtle difference, but understanding it helped me appreciate how Solana manages accounts under the hood.

What I'd tell myself on Day 64

If I could go back to when I started this project, I'd probably leave myself these notes:

Your program ID is part of every PDA derivation. The same seeds in another program produce a completely different address.
A PDA cannot sign transactions by itself. Your program signs on its behalf using the same seeds.
Seeds determine your data model. Think carefully before choosing them.
Don't treat init_if_needed as your default solution. It's useful, but it's easy to misuse if you don't fully understand when accounts should already exist.
Breaking things on purpose taught me more than reading another tutorial ever did.

Final thoughts

This week wasn't just about building a counter program.

It was about understanding how Solana thinks about state.

PDAs stopped feeling like some cryptographic trick and started feeling like a practical design tool. Once that mental model clicked, the rest of my Anchor code became much easier to reason about.

I'm still learning, but I can already tell this is one of those concepts that changes how you design Solana programs.

If you're learning PDAs too, I'd recommend reading the official Solana PDA documentation alongside the Anchor PDA guide, then building something simple and deliberately changing the seeds to see what breaks. That's the exercise that made everything click for me.

100DaysOfSolana

Day 62 #100daysofsolana: How I Built My First Anchor Counter Program and Learned to Trust My Tests

Peter Okoh — Sat, 18 Jul 2026 10:59:39 +0000

There's something satisfying about seeing your tests pass after spending days building, breaking, fixing, and rebuilding the same program.

Over the past week, I worked on a simple counter program with Anchor. At first glance, it doesn't look like much, it just initializes a counter and increments it. But behind those few lines of code are some important lessons about Solana programs, account validation, and why good tests matter.

The first thing that stood out to me was the Initialize accounts struct. Coming from a more traditional development background, it took me a while to appreciate that most of the "magic" in Anchor happens before your instruction logic even runs. The accounts struct defines exactly which accounts are needed, who owns them, who pays for them, and what constraints must be satisfied. Once I understood that, the rest of the program started making a lot more sense.

The initialize handler itself is surprisingly short. That's because ctx.accounts gives you direct access to all the validated accounts you declared earlier. Instead of writing lots of validation logic yourself, Anchor handles it for you. All the handler needs to do is set the initial value of the counter.

The increment instruction taught me another valuable lesson. By adding an account constraint that checks the authority, I learned that security doesn't always belong inside the function body. Anchor verifies those constraints before the instruction executes, preventing unauthorized users from incrementing someone else's counter. That small addition made me appreciate how much safer programs can become when validation is built into the framework.

Writing the tests was where everything really clicked.

The happy-path test confirmed that a newly initialized counter starts with the expected value and increments correctly. If that test ever fails, it means the program's core functionality is broken.

The unauthorized increment test became my favorite. It attempts to increment a counter using the wrong wallet and expects the transaction to fail. If that test unexpectedly passes, it means anyone could modify someone else's counter, a serious security flaw. That single test gave me much more confidence in the program.

One of the most eye-opening exercises was intentionally introducing bugs into the code. For one experiment, I changed:

counter.count += 1;

counter.count += 2;

I expected everything to compile, and it did. But my tests immediately failed because the final counter value was no longer what the assertions expected.

That moment reinforced an important lesson for me: passing compilation doesn't mean your program is correct. Tests are what prove your code behaves the way you intended.

This project may be a simple counter, but it taught me much more than incrementing numbers. It helped me understand how Anchor validates accounts, how instruction handlers stay clean because of those validations, and why writing failure-path tests is just as important as testing successful transactions.

If I had another week to improve this project, I'd explore custom error codes, event logging, Program Derived Addresses (PDAs), and more advanced account relationships to better understand how real-world Solana programs are structured.

Small projects often teach the biggest lessons.

100DaysOfSolana #Solana #Anchor #Rust #Testing #BuildInPublic

DAY 55 #100DaysOfSolana: Three Token-2022 Mints in One Week: Transfer Fees, Interest-Bearing Tokens, and Soulbound Assets

Peter Okoh — Tue, 30 Jun 2026 15:40:30 +0000

Coming from Web2, I used to think a token was just a balance in a database. If you wanted extra behavior—transaction fees, rewards, or restrictions, you'd probably build it into your application logic.

Token-2022 changed that perspective for me. It's the upgraded SPL Token Program that lets you attach extensions directly to a token mint. I like to think of these extensions as middleware. Instead of creating an entirely new token standard, you opt into the features your application needs while keeping the same underlying protocol. This week, I experimented with three different extensions, and each one completely changed how I think about designing tokens on Solana.

1. Transfer Fee Extension

Creating the mint

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 6 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000

After minting tokens, I transferred 1,000 tokens to another wallet.

Something interesting happened.

The recipient didn't receive 1,000 tokens.

Instead, the balance became:

Balance: 990
Transfer fees withheld: 10000000

The remaining tokens were automatically withheld as transfer fees by the token program itself.

Later, I withdrew the withheld fees:

spl-token withdraw-withheld-tokens $MY_TA $RECIPIENT_TA

After that:

Balance: 1000
Transfer fees withheld: 0

Watching the fee move through the system automatically made the feature click for me.

When would I actually use this?

This extension makes perfect sense for a community token or creator economy where every transfer contributes a small percentage to a project treasury. Instead of relying on off-chain accounting, the token program enforces the fee every single time.

2. Interest-Bearing Extension

Creating the mint

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --decimals 6 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000 \
  --interest-rate 5000

After minting tokens, I checked the balance twice, about 30 seconds apart.

The displayed balance changed from:

1000062.476727

1000062.967937

That was unexpected.

At first, I assumed new tokens were being minted.

They weren't.

The Interest-Bearing extension **does not create additional supply.

Instead, it updates the displayed UI amount using the configured interest rate while the underlying token supply remains unchanged. That distinction is subtle, but it's an important one because it changes how you think about accounting and token economics.

3. Non-Transferable (Soul-Bound) Token

Creating the mint

spl-token create-token \
  --program-2022 \
  --enable-non-transferable

I minted one token to my wallet and then created another wallet to test whether I could transfer it.

Naturally, I expected the transfer to work.

It didn't.

Running:

spl-token transfer $MINT 1 $RECIPIENT --allow-unfunded-recipient

returned:

Program log: Transfer is disabled for this mint

That single error message perfectly demonstrates the purpose of this extension.

Once a token is marked as non-transferable, ownership cannot simply be passed around like a regular SPL token.

I immediately started thinking about applications like:

digital certificates
university credentials
employee IDs
membership badges
proof-of-attendance tokens

These are assets that represent identity rather than value, so allowing them to be traded would defeat their purpose.

Final Thoughts

This week completely changed how I think about tokens on Solana.

Before Token-2022, I imagined every special token behavior required a custom smart contract. Instead, I learned that many of these capabilities already exist as modular extensions you can opt into when creating a mint.

The Transfer Fee extension showed me how protocol-level fees can replace application logic. The Interest-Bearing extension taught me the difference between changing displayed balances and changing token supply. And the Non-Transferable extension demonstrated how the token program itself can enforce ownership rules without any additional code.

If I were building a real product today, I'd happily reach for these extensions instead of reinventing them. That's probably the biggest lesson I've taken away from this part of my Solana journey: sometimes the best engineering decision isn't writing more code, it's knowing which features the platform already gives you.

This post is part of my #100DaysOfSolana journey. If you're exploring Solana from a Web2 background, I hope this saves you a few hours of experimentation. Feel free to connect or share what you're building, I'd love to learn from your experience too.

Week 7: #100DaysOfSolana: What I Learned Minting NFTs on Solana with Token Extensions

Peter Okoh — Mon, 29 Jun 2026 15:08:57 +0000

Before this week, I assumed creating NFTs on Solana meant using Metaplex. That was the mental model I had carried for a while.

It turns out you can mint a complete NFT, with metadata, collection membership, and on-chain verification, using Solana's Token Extensions. That completely changed how I think about NFTs on Solana.

The Mental Model

One of the biggest lessons I learned this week is that an NFT on Solana isn't magic.

At its core, it's simply:

A token mint with a total supply of 1
0 decimals, making it indivisible
Metadata attached through the Metadata Extension
Optionally grouped into a collection using the Group and Member extensions

Once I understood that, everything else started making sense. Instead of seeing NFTs as a special asset type, I started seeing them as standard tokens with a few carefully chosen extensions.

That shift alone made the entire architecture much easier to understand.

What I Built

Over the past few days, I built my first NFT entirely with Token Extensions.

The journey included:

Creating a mint with supply 1
Attaching on-chain metadata
Adding the NFT to a collection using the Group and Member extensions
Auditing every byte stored on-chain
Updating the metadata on Devnet to understand how mutable NFTs work

Seeing everything reflected on Solana Explorer after each step made the process feel much more real than simply reading documentation.

One of the commands that stood out during the process was:

spl-token initialize-metadata \
  <MINT_ADDRESS> \
  "My First NFT" \
  "MNFT" \
  https://example.com/metadata.json

Watching the metadata become part of the mint itself was one of those "now I get it" moments.

What Surprised Me

Coming from a Web2 background, I expected NFTs to involve a lot of custom infrastructure.

Instead, I discovered that much of the functionality comes directly from Token Extensions.

I also expected metadata to be something hidden behind another protocol. Instead, I learned that it can live directly on the mint account.

Another surprise was how transparent everything is.

Every instruction, every account, every byte of metadata can be inspected on-chain. I even wrote an audit script to verify exactly what had been stored.

That level of visibility makes debugging far less mysterious than I initially expected.

What I'd Build Next

Now that I understand how Token Extensions fit together, there are a few things I'm excited to explore next:

Building an NFT minting application with a simple frontend
Experimenting with immutable metadata
Creating collection management tools
Exploring programmable NFTs and compressed NFTs

This week gave me a much stronger mental model of how NFTs actually work on Solana, and that's far more valuable than simply knowing the commands.

The biggest takeaway wasn't learning how to mint an NFT.

It was understanding what an NFT really is.

For any Web2 developer curious about Solana, I'd encourage you to spend time learning Token Extensions before reaching for higher-level frameworks. Understanding the foundation makes everything else much easier.

This post is part of my #100DaysOfSolana journey. If you're learning Solana too, I'd love to connect and hear what you're building.

Week 5 #100DaysOfSolana: Not Just Minting Tokens Anymore, Building Systems

Peter Okoh — Fri, 29 May 2026 11:46:43 +0000

Today felt less like “following tutorials” and more like actually becoming a builder.

I just built a complete token from scratch in one sitting.

Metadata.
Minting.
Transfers.
Transfer fees.
Everything tied together into one working flow.

And the best part?
I wasn’t trying to learn something new today.

I was proving to myself that I could connect everything I’ve learned over the past few days without relying on step-by-step guidance.

That feeling hits differently.

What continues to amaze me about Solana is how much infrastructure the protocol already provides.

In Web2, building something like this would mean setting up databases for balances, APIs for transfers, payment systems for fees, and backend logic to connect everything together.

But on Solana, the mint itself carries the configuration.
The Token Extensions Program enforces the rules.
Metadata lives directly on-chain.

And somehow… all of that came together through a few CLI commands.

Today reinforced something important for me:
Creating, configuring, minting, transferring, and collecting fees isn’t just a random exercise.

It’s a real pattern.
A real workflow.

And I can already see how this foundation leads into building more complex systems later on.

Still learning.
Still experimenting.
But for the first time, I genuinely feel like I’m building with intention instead of just copying commands.

Day32

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.

DEV Community: Peter Okoh

Day 76 #100daysofsolana: The CPI Mental Model I Wish I Had on Day 71

The mental model that finally made sense

A real example from my project

What tripped me up

My biggest takeaway

100daysofsolana

Day 69 #100daysofsolana: What a Week of Building on Solana Taught Me About Program Derived Addresses (PDAs)

Why do PDAs even exist?

The mental model that finally clicked

Breaking down my own PDA

Why your seeds matter

What the bump actually buys you

The lifecycle of a PDA

What I'd tell myself on Day 64

Final thoughts

100DaysOfSolana

Day 62 #100daysofsolana: How I Built My First Anchor Counter Program and Learned to Trust My Tests

100DaysOfSolana #Solana #Anchor #Rust #Testing #BuildInPublic

DAY 55 #100DaysOfSolana: Three Token-2022 Mints in One Week: Transfer Fees, Interest-Bearing Tokens, and Soulbound Assets

1. Transfer Fee Extension

Creating the mint

When would I actually use this?

2. Interest-Bearing Extension

Creating the mint

3. Non-Transferable (Soul-Bound) Token

Creating the mint

Final Thoughts

Week 7: #100DaysOfSolana: What I Learned Minting NFTs on Solana with Token Extensions

The Mental Model

What I Built

What Surprised Me

What I'd Build Next

Week 5 #100DaysOfSolana: Not Just Minting Tokens Anymore, Building Systems

Day32

From Web2 Complexity to On-Chain Simplicity

Day31

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

Day30

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

WEEK 4 #100DaysOfSolana: LAMPORTS IN SOLANA

Week 4 #100DaysOfSolana: My Explorer

100daysofsolana

Day28

Week 4: #100DaysOfSolana; Account Model

100DaysOfSolana

Day27