DEV Community: Tobi Ayinmiro

The CPI Mental Model I Wish I Had on Day 71

Tobi Ayinmiro — Mon, 06 Jul 2026 10:02:07 +0000

Cross-Program Invocation isn't magic. It's just a function call with a guest list.

When I first came across Cross-Program Invocations (CPIs) in Solana, I thought they were some special feature that required a completely different way of thinking. Every example introduced CpiContext, account structs, and signer seeds all at once, and I couldn't tell which pieces were essential and which were just Anchor boilerplate.

After spending the last few days building programs that call the System Program, sign for PDAs, and even call another Anchor program, I realized that the whole idea is much simpler than I originally thought.

My mental model is this:

A CPI is just a function call with three things: the program you're calling, the accounts that program expects, and who is authorized to sign.

Once that clicked, every CPI example started looking almost identical.

The Mental Model

Every Cross-Program Invocation has three moving parts.

1. The program being called

Every CPI targets another on-chain program. That might be the System Program, the Token-2022 Program, or another program you wrote yourself. Anchor identifies that program by its program ID.

2. The accounts that program needs

Programs cannot magically access accounts. Your program has to pass every required account to the program you're calling.

If the called program expects a from account, a to account, and a system program account, you must provide all three.

This is why CPIs often feel like filling out a checklist rather than writing complicated logic.

3. The signer

This was the piece that confused me the most.

Sometimes the signer is simply the wallet that signed the transaction.

Other times, the signer is a Program Derived Address (PDA). Since PDAs don't have private keys, the runtime lets the program "sign" for them—but only if the signer seeds exactly match the PDA's seeds.

That means the seeds used in with_signer() must match the seeds declared in your #[account(seeds = ..., bump)] constraint. If they don't match, the runtime rejects the CPI.

A Small Example

One of the first examples that made this pattern click was calling another Anchor program.

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

    cpi::increment(cpi_ctx)?;
    Ok(())
}

Even though this looked unfamiliar at first, it's really just following the same three-part pattern.

The program being called is counter_program.
The account it needs is tally.
No PDA is signing here, so a regular CpiContext::new() is enough.

Earlier in the week I used the exact same pattern to call the System Program to transfer SOL. The only difference was the destination program and the accounts passed into the context.

The structure stayed exactly the same.

What Tripped Me Up

The biggest lesson from building a PDA-backed vault wasn't actually writing the transfer it was understanding why with_signer() exists.

When withdrawing from my vault, the vault account itself had to authorize the transfer. But the vault is a PDA, and PDAs don't have private keys.

The solution was:

.with_signer(signer_seeds)

where signer_seeds matched the PDA declaration:

#[account(
    seeds = [b"vault", user.key().as_ref()],
    bump,
)]

That finally made the idea click.

The program isn't inventing a signature. It's proving to the runtime that it controls the PDA by supplying the exact seeds that generated it.

Once I understood that, PDA signing stopped feeling mysterious.

Final Thoughts

If I could go back to Day 71, I wouldn't start by memorizing CpiContext or invoke_signed.

I'd start with the question:

Who am I calling, what accounts does that program need, and who is allowed to sign?

Everything else is just implementation details.

Whether you're calling the System Program, Token-2022, or another Anchor program, that same mental model keeps showing up.

This post draws on my work from Days 73-74 of #100DaysOfSolana, covering PDA-signed transfers and Cross-Program Invocations between Anchor programs.

What I Learned About PDAs in a Week of Building on Solana

Tobi Ayinmiro — Mon, 29 Jun 2026 14:40:45 +0000

What problem do PDAs solve?

One of the first things that confused me when learning Solana was where programs actually store data.

Unlike a traditional backend, Solana programs are stateless. They don't keep variables in memory between requests. Every piece of persistent data has to live inside an account.

That immediately creates a problem.

If my counter program needs to remember a counter for every user, how does it know where to find that user's data tomorrow?

Program Derived Addresses (PDAs) solve exactly that problem. They let a program deterministically derive the same account address every time from known inputs without storing the address anywhere beforehand.

Over the past week (Days 64–68 of the 100 Days of Solana challenge), I built a counter program that evolved from a simple PDA into a complete application with:

one counter PDA per wallet
a global config PDA
account constraints
pause functionality
rent recovery through account closing
experiments showing how seed choices affect security

Here is the mental model that finally made PDAs click for me.

The mental model

Coming from Web2, the closest analogy is a deterministic database key.

Imagine a users table where every counter row is identified by:

("counter", user_id)

Instead of generating a random UUID, you always compute the primary key from known values.

A PDA works similarly.

Rather than storing an address somewhere, Solana computes it from:

one or more seeds
the program ID
a bump value

That means the program can always derive the same address later.

Unlike a database row, though, a PDA is not automatically created.

You can derive a PDA today that has no account living at that address.

The account only exists after your program initializes it.

Anatomy of a derivation

This is the exact account constraint from 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>,

Every line matters.

`init`

Create the account if it doesn't already exist.

`payer = user`

The wallet pays the rent-exempt storage deposit.

`space`

Anchor reserves enough bytes for the account.

The extra 8 bytes are Anchor's discriminator.

`seeds`

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

This is the logical identity of the account.

The first seed is static.

The second seed is dynamic.

Together they uniquely identify one counter for one wallet.

`program ID`

The program ID is automatically included in the derivation.

That means another Solana program using identical seeds produces an entirely different PDA.

This was one of the biggest "aha" moments for me.

The program ID is part of the address.

What is the bump?

When Solana derives a PDA, it repeatedly hashes:

seeds
+
program ID
+
candidate bump

starting from 255 downward.

It keeps trying until the resulting public key lands off the Ed25519 curve.

That final successful byte is called the canonical bump.

During Day 64 I used:

PublicKey.findProgramAddressSync(...)

which returned both:

[pda, bump]

Anchor stores that bump for me automatically:

counter.bump = ctx.bumps.counter;

Later instructions reuse it:

bump = counter.bump

Why the seeds matter

The seed design determines your entire data model.

During Day 68 I experimented with different derivations.

This script:

PublicKey.findProgramAddressSync(
    [Buffer.from("counter"), walletA.toBuffer()],
    program.programId
)

produced a completely different PDA than:

PublicKey.findProgramAddressSync(
    [Buffer.from("counter"), walletB.publicKey.toBuffer()],
    program.programId
)

Every wallet got its own counter.

Exactly what I wanted.

Then I removed the wallet from the seeds.

[Buffer.from("counter")]

Both wallets derived the exact same PDA.

That would create a single global counter.

Sometimes that's perfect.

For example, my config account intentionally uses:

seeds = [b"config"]

because the whole program only needs one configuration.

But if my counter used the same seed scheme, every user would be sharing one counter account.

The first initialization would succeed.

Everyone else would receive:

account already in use

That experiment made the importance of seed selection much clearer than reading documentation alone.

What the bump buys you

The bump is not random.

It is the canonical value that successfully generated an off-curve PDA.

Anchor automatically computes it when you write:

bump

and later validates it with:

bump = counter.bump

Since the bump never changes, storing it inside the account is effectively free.

Reusing the stored bump also avoids recalculating it every instruction.

My counter stores it during initialization:

counter.bump = ctx.bumps.counter;

and every later instruction validates the same PDA using that stored value.

The full lifecycle of a PDA

One thing I appreciated about this week is that I saw the complete lifecycle.

Day 64

Learn how to derive a PDA.

findProgramAddressSync()

Day 65

Actually create the account.

init

One wallet.

One counter PDA.

Day 66

Introduce a second PDA.

My program now had:

Config PDA
Counter PDA

I also added constraints like:

has_one = user

and

constraint = !config.paused

so invalid transactions were rejected before my handler even ran.

Day 67

Delete the account.

close = user

The close instruction looked almost empty:

pub fn close_counter(
    _ctx: Context<CloseCounter>
) -> Result<()> {
    Ok(())
}

Anchor handled everything else.

When the instruction completed:

account data was cleared
lamports were refunded
the runtime removed the account

This isn't the same as deleting a database row.

The runtime drains the lamports, zeroes the data, and garbage-collects the account afterward.

Day 68

Break things on purpose.

I wrote a script that tried to spoof another user's PDA.

await program.methods
    .increment()
    .accounts({
        counter: pdaB,
        user: walletA,
    })
    .rpc();

Anchor rejected it immediately.

Why?

Because the account constraint re-derived the PDA from Wallet A's public key and discovered that I had passed Wallet B's PDA instead.

No manual ownership check.

No custom security code.

The constraint itself enforced the rule.

That was probably the biggest takeaway of the week.

What I would tell past me

The program ID is part of every PDA derivation. The same seeds in another program produce a different address.
A PDA is only an address. It does not become an account until your program initializes it.
Seed design is your data model. Choose them carefully.
Store the bump once and reuse it instead of deriving it every instruction.
init_if_needed is convenient, but I now understand why people call it a footgun. Use it intentionally.
Account constraints are much more than syntax—they are a major part of your program's security.

Final thoughts

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

At first, PDAs felt like magic.

Looking back, the biggest lesson wasn't how to derive a PDA it was learning that your seed design is your data model.

In Web2, you spend time designing database schemas, primary keys, and relationships because they determine how your application behaves.

On Solana, you spend that same effort designing your PDA seeds.

The difference between:

["counter"]

and

["counter", user]

is the difference between one shared counter for the entire application and one counter for every user.

That isn't just an implementation detail it defines the structure of your application.

Once I started thinking of PDA seeds the same way I think about database schema design, the rest of Solana's account model became much easier to understand.

For Web2 developers, that mental model is what finally made everything click for me.

If you're learning Solana, I highly recommend reading the official Solana PDA documentation, the Anchor PDA guide, and the Anchor crate documentation alongside building your own small project. The combination of reading and experimenting is what made these concepts stick for me.

You can also find the full source code for my counter program on my GitHub repository.

How I Built My First Anchor Counter Program and Learned Why Tests Matter

Tobi Ayinmiro — Mon, 22 Jun 2026 10:29:02 +0000

This week I built my first Solana program with Anchor: a simple counter that starts at 0 and can only be incremented by its owner.

The first thing that helped me understand Anchor was the Initialize accounts struct:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
    )]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

The counter account is the on-chain account that stores the data. The authority account is the wallet creating the counter and paying for the account creation. The system_program is needed because Solana uses it to create new accounts.

The initialize handler is very short:

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;
    counter.authority = ctx.accounts.authority.key();
    counter.count = 0;
    Ok(())
}

ctx.accounts gives me access to all the validated accounts from the Initialize struct. Here I simply save the owner's wallet address and set the counter value to zero.

The increment instruction is also small:

pub fn increment(ctx: Context<Increment>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;
    counter.count = counter.count
        .checked_add(1)
        .ok_or(ProgramError::ArithmeticOverflow)?;
    Ok(())
}

The important security check is actually here:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut, has_one = authority)]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

The has_one = authority constraint makes sure only the wallet that owns the counter can increment it. Anchor checks this before the instruction logic runs.

Testing the Happy Path

My main test initializes a counter, increments it, and checks that everything was stored correctly.

#[test]
fn initialize_then_increment() {
    // initialize counter
    // increment counter
    // verify count == 1
    // verify authority is correct
}

This test would fail if the counter was not initialized correctly or if incrementing did not update the value as expected.

Testing the Failure Path

I also wrote a test to make sure a different wallet cannot increment someone else's counter.

#[test]
fn increment_fails_when_wrong_authority_signs() {
    // create counter with authority_a
    // attempt increment with authority_b
    // expect transaction to fail
}

This test would fail if my ownership check stopped working and unauthorized users were allowed to modify the counter.

Breaking the Program on Purpose

For Day 61, I intentionally introduced bugs to make sure my tests were actually protecting me.

One experiment changed:

.checked_add(1)

to:

.checked_add(2)

The transaction still succeeded, but the test failed because the counter became 2 instead of 1.

The failing assertion looked like this:

assertion `left == right` failed
left: 2
right: 1

That was a great reminder that a transaction can succeed while still producing the wrong result. Without the test, I might not have noticed the bug.

What I'd Build Next

If I had another week, I'd expand this project by supporting multiple counters per user, and adding more edge-case tests.

The biggest lesson from this project was that writing tests is useful, but intentionally breaking the program and watching the tests catch the bug is what really builds confidence in them.

Token-2022 Feels Like Middleware for Money

Tobi Ayinmiro — Wed, 17 Jun 2026 08:50:42 +0000

As a Web2 developer, I naturally compare new technologies to tools I've already used.

After spending a week exploring Solana's Token-2022 program, I realized the best analogy is middleware.

Instead of wrapping requests, you're wrapping assets.

With Token-2022 extensions, behaviors that would normally require custom smart contracts can be attached directly to a token mint. Over the past few days, I created three different Token-2022 mints on devnet and experimented with transfer fees, interest accrual, and non-transferability.

Day 50–51: Transfer Fee Token

Mint Address

2Ak24WKZZrvjE4KGWr8YMovGBsWB5bptcQekFycn5jpd

Create Token

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

Test Transfers

export MINT=2Ak24WKZZrvjE4KGWr8YMovGBsWB5bptcQekFycn5jpd

spl-token mint $MINT 1000000

spl-token transfer \
  --expected-fee 10 \
  $MINT 1000 $RECIPIENT \
  --allow-unfunded-recipient

Harvest Collected Fees

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

The Transfer Fee extension automatically withholds a percentage of every transfer. In a traditional Web2 application, implementing this would typically require backend logic, payment processing, and accounting systems. With Token-2022, the rule is enforced directly by the token itself.

Potential use cases include protocol fees, creator royalties, treasury funding, and community currencies.

Day 52: Interest-Bearing Token

Mint Address

86D7eecNMkJMofFabFq9GMFPPUVYrwLbLx3KA6vnAyee

Create Token

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

Observe Interest Accrual

spl-token accounts $MINT --verbose

sleep 30

spl-token accounts $MINT --verbose

This extension surprised me the most.

Unlike traditional interest-bearing assets, the underlying token balance does not increase over time. Instead, Token-2022 adjusts the displayed UI amount to reflect accrued interest.

The result is a token that appears to grow while maintaining the same underlying balance. This allows applications to represent yield without continuously minting new tokens.

Day 54: Non-Transferable Token

Mint Address

Ek7ViTTtLeMCXGgBBuxUcnbxNweN58EJhTAkzcfkKi8k

Create Token

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

Attempt a Transfer

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

Actual Result

The transfer failed exactly as expected.

Transfer 1 tokens
  Sender: AUVDPscnF5YwhSd5oKKVFiASVLJvzix9v9rT6SFiUaTk
  Recipient: A8MAafu4XrCxetfZhMWtSoSMXarzUBeXX5yUrcHqdCxq
  Recipient associated token account: 4BkZZy8r1uaraL4PRu6CgNAvA8HhBEhcBMcmPgexB46C

Error: Client(Error {
  request: Some(SendTransaction),
  kind: RpcError(RpcResponseError {
    code: -32002,
    message: "Transaction simulation failed:
    Error processing Instruction 0:
    custom program error: 0x25",
    data: SendTransactionPreflightFailure(
      RpcSimulateTransactionResult {
        err: Some(
          UiTransactionError(
            InstructionError(0, Custom(37))
          )
        ),
        logs: [
          "Program log: Instruction: TransferChecked",
          "Program log: Transfer is disabled for this mint"
        ]
      }
    )
  })
})

The important part of the error is:

Program log: Transfer is disabled for this mint

This confirms that the Non-Transferable extension was functioning exactly as designed. The Token-2022 program prevented the asset from being transferred between wallets, enforcing the restriction at the protocol level rather than relying on application logic.

Unlike standard SPL tokens, these assets are intended to remain attached to the wallet that receives them.

Potential use cases include:

Educational certificates
Membership badges
Event attendance proofs
Reputation systems
Identity credentials
Soul-bound tokens

Rather than functioning as currency, these tokens act as verifiable digital records tied to a specific wallet.

Why This Matters

What stood out to me throughout this exercise was how much functionality can be configured without writing a custom Solana program.

In a typical Web2 architecture, implementing these features would likely require:

APIs
Databases
Background jobs
Access-control logic
Payment processing systems

With Token-2022, many of these behaviors can be embedded directly into the asset itself.

A transfer fee becomes part of the token.

Interest accrual becomes part of the token.

Transfer restrictions become part of the token.

The asset carries the logic.

Final Thoughts

Token-2022 has changed how I think about digital assets on Solana.

Instead of building applications around tokens, developers can increasingly build behavior into the tokens themselves.

Over the course of these experiments, I created:

A token that collects fees
A token that accrues interest
A token that cannot be transferred

All without deploying a custom smart contract.

For a Web2 developer, the closest analogy remains middleware—but middleware for money.

The most interesting lesson from this week was seeing how different token behaviors can be achieved through configuration alone. Features that would traditionally require custom contracts, backend services, or application-level enforcement can be attached directly to the asset at mint creation.

That's a powerful shift in how we think about designing digital assets.

Creating My First Token on Solana Devnet as a Web2 Developer

Tobi Ayinmiro — Mon, 25 May 2026 10:45:56 +0000

As a web developer, I’m used to building systems where currencies, rewards, and balances live inside databases controlled by the backend.

This week was my first time creating an actual on-chain token on Solana, and honestly, it changed how I think about digital assets.

Instead of storing balances in a database table, the blockchain itself handled everything — minting, transfers, metadata, and verification.

In this post, I’ll walk through how I created my first token on Solana devnet using Token-2022, added metadata to it, minted supply, and transferred tokens between wallets.

What I Needed Before Starting

Before creating the token, I needed:

Solana CLI installed
SPL Token CLI installed
A funded devnet wallet
Solana configured to devnet

First, I configured Solana to use devnet:

solana config set --url devnet

Then I requested free devnet SOL:

solana airdrop 2

Creating My First Token Mint

Unlike the older SPL Token Program, I used the newer Token-2022 Program because it supports extensions like:

Metadata
Transfer fees
Interest-bearing tokens
Non-transferable (soulbound) tokens

Here’s the command I used:

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

After running it, Solana generated a token mint address for me.

At this point, the token technically existed on-chain, but it still had no identity.

It was basically just a random string of characters.

Adding Metadata to the Token

This was one of the coolest parts for me.

I learned that Solana’s Token-2022 Program allows metadata to live directly on-chain instead of depending entirely on separate programs.

I initialized the token metadata like this:

spl-token initialize-metadata \
  <TOKEN_MINT_ADDRESS> \
  "<TOKEN_NAME>" \
  "<TOKEN_SYMBOL>" \
  "<TOKEN_METADATA_URI>"

Example placeholders:

<TOKEN_MINT_ADDRESS> → your token mint address
<TOKEN_NAME> → e.g. MyCoin
<TOKEN_SYMBOL> → e.g. MYC
<TOKEN_METADATA_URI> → public JSON metadata link

At this point, my token finally had:

a name
a symbol
metadata attached to it

That made it feel like a real digital asset instead of just raw blockchain data.

Creating a Token Account

One concept that confused me initially was token accounts.

I assumed my wallet could directly hold tokens.

That’s not exactly how Solana works.

On Solana:

the mint defines the token
token accounts hold balances for that token

So before I could receive my token, I had to create a token account:

spl-token create-account <TOKEN_MINT_ADDRESS>

This generated an associated token account tied to my wallet and token mint.

Minting My First Supply

Now came the exciting part.

I minted 1000 tokens into my token account:

spl-token mint <TOKEN_MINT_ADDRESS> 1000

Then I checked the balance:

spl-token balance <TOKEN_MINT_ADDRESS>

And seeing this:

it felt surprisingly rewarding to be honest

Creating a Second Wallet

To test transfers properly, I created a second wallet:

solana-keygen new \
  --outfile ~/second-wallet.json \
  --no-bip39-passphrase

This simulated sending tokens to another user.

Transferring Tokens

I transferred 250 tokens to the second wallet:

spl-token transfer \
  <TOKEN_MINT_ADDRESS> \
  250 \
  $(solana-keygen pubkey ~/second-wallet.json) \
  --fund-recipient \
  --allow-unfunded-recipient

The --fund-recipient flag automatically created the recipient’s token account if it didn’t already exist.

That was another thing that clicked for me:
even receiving tokens on Solana involves token accounts behind the scenes.

Verifying the Transfer

I checked both balances.

My wallet balance:

spl-token balance <TOKEN_MINT_ADDRESS>

Recipient wallet balance:

spl-token balance \
  --owner $(solana-keygen pubkey ~/second-wallet.json) \
  <TOKEN_MINT_ADDRESS>

The balances showed:

750 in my wallet
250 in the second wallet

The transfer worked successfully.

What Confused Me Initially

One of the biggest things that confused me was the difference between:

wallet addresses
token accounts
token mints

At first, I thought:

“Why can’t I just send directly to the wallet?”

But Solana separates:

the wallet owner
the token account holding balances
the token definition itself

Once that clicked, the entire token system started making much more sense.

What Surprised Me Most

The biggest surprise was realizing how much logic the blockchain itself handles.

In Web2, building something similar would require:

database tables
backend APIs
transfer validation
balance management
permission handling

On Solana:

the protocol handles balances
token programs enforce rules
transactions are verifiable on-chain

It felt like moving backend business logic directly into infrastructure.

Final Thoughts

Creating my first token on Solana made Web3 feel much less abstract.

Before this, tokens felt like mysterious blockchain concepts.

Now I understand that they’re actually programmable digital assets with rules enforced directly by the protocol.

This was my first step into Solana development, and it definitely won’t be the last.

Next, I want to explore:

transfer fee extensions
soulbound tokens
Solana programs with Rust
building full-stack dApps

If you’re coming from Web2 development, my advice is simple:

Start building.

Things make much more sense once you actually create something yourself.

link to the token: https://explorer.solana.com/address/vXRh8HHmjeFvpQgt19EEqf6iaAQxqM8NtCdTwCAqozu?cluster=devnet

Understanding Solana’s Account Model as a Web2 Developer

Tobi Ayinmiro — Mon, 18 May 2026 08:56:42 +0000

Understanding Solana’s Account Model as a Web2 Developer

When I started learning Solana, I expected wallets and smart contracts to work like Ethereum. Instead, I discovered something very different:

On Solana, everything is an account.

At first, that sounded simple. But it completely changed how I thought about blockchain architecture.

As a Web2 developer, I’m used to systems that look like this:

Frontend → Backend API → Database

The backend stores logic
The database stores state

Solana works differently — but underneath it all is a surprisingly familiar mental model.

The easiest way to understand Solana’s account model is to think of it like a filesystem or operating system:

Accounts = files
Programs = executable applications
Data accounts = databases/documents
The System Program = operating system kernel

Once this clicks, the rest of Solana becomes much easier to understand.

Everything on Solana Is an Account

Unlike Ethereum, which separates:

externally owned accounts (wallets)
contract accounts (smart contracts)

Solana uses a unified account model for everything.

On Solana:

wallets are accounts
programs are accounts
tokens are accounts
NFT metadata lives in accounts

Everything exists inside one giant flat key-value store.

key   = public address
value = account data

Or, if you’re thinking like a backend developer:

Map<PublicKey, Account>

That simplicity is one of the reasons Solana can process transactions efficiently.

Every Solana Account Has the Same Structure

Every account contains the same core fields:

Field	Purpose
`lamports`	SOL balance
`data`	Raw bytes storing state
`owner`	Program allowed to control the account
`executable`	Whether the account contains executable code
`rent_epoch`	Deprecated rent-related field

Let’s break them down.

1. Lamports

Lamports are the smallest unit of SOL.

1 SOL = 1,000,000,000 lamports

Similar to:

dollars → cents
bitcoin → satoshis

Example:

500000000 lamports = 0.5 SOL

Lamports are used for:

transaction fees
storing accounts
transferring SOL

2. Data

The data field stores arbitrary bytes.

This is where programs save state, including:

token balances
NFT metadata
usernames
protocol configuration
DeFi positions

Unlike traditional databases, Solana does not store JSON directly.

Everything is serialized into bytes.

For Web2 developers, this feels more like:

binary storage
buffers
low-level database records

3. Owner

The owner field is one of the most important concepts in Solana.

It defines which program controls an account.

Example:

Owner: Token Program

That means only the Token Program can:

modify the account’s data
debit lamports from the account

This is the foundation of Solana’s security model.

Ownership Rules

Solana follows a surprisingly simple set of rules:

Only the owner program can:

modify account data
remove lamports from the account

But anyone can:

send lamports to a writable account

Without ownership rules, any program could edit any account’s data.

Imagine random APIs directly modifying your production database tables.

That would be chaos.

Solana prevents this through program ownership.

4. Executable

The executable field is simply a boolean.

true  = account contains program code
false = account stores data

If executable = true, the account contains compiled program code.

Otherwise, it’s just a data account.

5. Rent Epoch

This field is mostly deprecated today.

Historically, it related to Solana’s rent system.

Now it’s typically set to a maximum value and ignored in most cases.

The Biggest Mindset Shift: Programs Don’t Store Their Own State

This was the concept that confused me the most.

On Solana:

Programs are stateless.

Smart contracts do not permanently store their own internal state.

Instead:

program accounts store executable code
separate accounts store persistent data

This is very different from Ethereum.

The Web2 Analogy That Made It Click

Think of a Solana program like a Node.js backend service.

The backend server:

contains logic
processes requests
validates data

But it does not permanently store all user data in memory.

Instead, it reads from and writes to a database.

Solana works the same way:

Program Account = Backend Server
Data Accounts   = Database Records

Programs execute logic.

Accounts store persistent state.

Example: A Todo App on Solana

Imagine building a Todo app.

Program Account

Contains logic like:

createTodo()
updateTodo()
deleteTodo()

Data Accounts

Store actual user data:

- todo text
- completed status
- owner wallet

The program modifies data accounts whenever users interact with the app.

Why Solana Separates Code From State

At first, this architecture feels inconvenient.

But it enables several powerful features:

parallel transaction execution
better scalability
clearer ownership rules
flexible storage patterns

Because accounts are separate from programs, Solana can determine which transactions touch which accounts.

That allows many transactions to execute simultaneously.

This is one of the major reasons Solana is fast.

Rent Exemption Explained

Every account on Solana must maintain a minimum balance to stay on-chain.

This is called:

rent exemption

The required amount depends on the account’s data size.

More data requires:

more storage
more lamports

For a tiny account with no additional data, the requirement is roughly:

~0.00089 SOL

You can check rent requirements with:

solana rent 0

Or via RPC:

getMinimumBalanceForRentExemption()

Why Rent Exists

In Web2 systems:

servers have storage limits
databases cost money

Solana validators also store account data permanently.

Without rent requirements, attackers could spam the network with millions of useless accounts.

Rent helps prevent storage abuse.

Reading a Real Solana Account

Using the CLI:

solana account <ACCOUNT_ADDRESS>

You might see:

Public Key: 7xKXtg2CW...
Balance: 0.002 SOL
Owner: System Program
Executable: false
Rent Epoch: 18446744073709551615
Data Length: 0

Here’s how to interpret it:

Field	Meaning
Public Key	Account address
Balance	SOL stored in the account
Owner	Program controlling the account
Executable	Whether it stores code
Data Length	Amount of stored data
Rent Epoch	Deprecated field

Once you understand these fields, Solana Explorer becomes much easier to read.

Example of an account detail

The System Program

One program you’ll constantly encounter is the System Program.

Think of it like the operating system kernel.

It handles:

account creation
SOL transfers
ownership assignment
storage allocation

Almost every Solana application interacts with it.

Comparing Solana to Ethereum

Ethereum

contracts store their own state
different account types exist
code and storage are tightly coupled

Solana

everything is an account
programs are stateless
state lives in separate accounts
unified account architecture

This is one of the biggest conceptual shifts for Web2 developers entering Solana.

Final Mental Model

Here’s the simplest way I now think about Solana:

Accounts       = Files
Programs       = Executable apps
Data Accounts  = Databases/documents
System Program = Operating system

Once the account model clicks, many other Solana concepts become easier to understand:

tokens
NFTs
staking
DeFi protocols
DAOs

They all build on the same foundation:

accounts
ownership
programs
data storage

And honestly, that unified design is one of the things that makes Solana so interesting to learn as a developer.

Solana Transactions Explained for Backend Developers

Tobi Ayinmiro — Sat, 09 May 2026 15:17:33 +0000

Learning Solana transactions completely changed how I think about backend systems.

At first, I treated transactions like normal API requests:

client → server → database → response.

But Solana transactions are different.

They’re signed, temporary, atomic state changes sent to a decentralized network. Instead of “calling a server,” you prepare instructions that validators execute on-chain.

The biggest shift for me was understanding:

recent blockhashes
signatures
atomic execution
compute limits

One thing that made it click for me was actually building and sending transactions with "@solana/kit".

import {
  createSolanaRpc,
  devnet,
  generateKeyPairSigner,
  airdropFactory,
} from "@solana/kit";

const rpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));

const signer = await generateKeyPairSigner();

const airdrop = airdropFactory({ rpc });

await airdrop({
  recipientAddress: signer.address,
  lamports: 1_000_000_000n,
});

console.log("Airdrop complete");

Oddly enough, failed transactions taught me the most.

Breaking transactions on devnet helped me understand how Solana programs actually execute internally.

Web3 development feels very different once you stop thinking in request/response patterns.

Solana transfer

Tobi Ayinmiro — Tue, 05 May 2026 10:36:40 +0000

Hey guys i just sent my first solana and we can all see it. blockchain = transparency

Understand transaction anatomy

Tobi Ayinmiro — Tue, 05 May 2026 09:48:17 +0000

Ever wondered what’s inside a Solana transaction? 👀
Just drop the signature into the explorer:https://explorer.solana.com/ and unlock everything status, wallets, tokens, and logs. Blockchain = open books.

From Confusion to Clarity: My Second Week with Solana

Tobi Ayinmiro — Sat, 02 May 2026 16:41:29 +0000

Week one felt like learning new vocabulary. Week two with Solana felt like trying to form actual sentences.
At first, nothing made sense accounts, lamports, RPC calls. But then something clicked: blockchain isn’t magic. It’s just a different way of organizing and accessing data.
The turning point for me was building a simple dashboard that reads on-chain data. Seeing real values update made everything feel tangible.
Compared to traditional APIs, working with RPC feels more raw and direct. There’s no middle layer simplifying things you’re responsible for understanding what the data means.
What surprised me most is how much responsibility is pushed to the developer. There’s power in that, but also complexity.
I’m still figuring out how to design systems properly in this environment, but I’m starting to see the bigger picture and I'm excited for what's to come.

100DaysOfSolana

Traditional Database vs Solana Accounts

Tobi Ayinmiro — Thu, 30 Apr 2026 13:33:47 +0000

Hey guys, i did a comparison of traditional database and solana account

Exploring web3

Tobi Ayinmiro — Sun, 26 Apr 2026 15:58:21 +0000

Day 7 of #100DaysOfSolana

I created my Solana devnet wallet and checked my balance for the first time. Seeing the transaction appear on-chain made Web3 feel real everything is verified publicly.

Next, I’m excited to build something that interacts with the blockchain using my wallet.