DEV Community: Elizabeth Afolabi

The Solana Security Checklist I Built After Breaking Solana Programs

Elizabeth Afolabi — Sat, 25 Jul 2026 18:17:41 +0000

During Arc 12 of the #100DaysOfSolana. I stopped trying to make my programs work. I started trying to break them. I wrote adversarial tests, generated random inputs with fuzz testing, reproduced real-world exploits like Wormhole and Cashio, and intentionally passed the wrong accounts into my instructions.

The biggest lesson wasn't how exploits happen. It was how surprisingly small the missing validation can be. By the end of the arc, I realized I wasn't just learning security techniques; I was building a checklist I'll probably use every time I write an Anchor program.

This checklist is for anyone building Solana programs with Anchor. It's not meant to replace an audit, but it is a practical list of questions I'll run through before every mainnet deployment to catch the kinds of mistakes that are easy to overlook.

Earlier in the challenge, I assumed that if my instruction received an account and deserialized it successfully, everything was probably fine. This arc completely changed that.

On Solana, any account can be passed into an instruction.

Deserializing an account only tells you how to read its bytes. It doesn't tell you:

who owns it
whether it's the account you expected
whether it should be allowed here

That's why so much of Solana security is simply validating assumptions before your business logic ever runs.

My Solana Program Security Checklist

1. Account Validation

The biggest lesson from reproducing the Wormhole and Cashio exploits was how small the root cause actually was. In both cases, the vulnerable program trusted an account before verifying that it was owned by the expected program. Because of the lack of validation, an attacker was able to provide a counterfeit account that appeared genuine enough to deserialize but was not the account intended by the program itself. In Wormhole, that error resulted in a loss of around $326 million. Cashio experienced a similar problem, leading to approximately $52 million being emptied.

Rebuilding the vulnerable pattern locally made this much more tangible than simply reading the post-mortems. It reinforced a simple rule I'll carry into every program I write: never trust an account just because it was passed into your instruction. Validate it first.

Checklist

Use typed Account<'info, T> whenever possible.
Only use UncheckedAccount when absolutely necessary.
If using UncheckedAccount, verify its owner manually.
Validate any remaining_accounts before using them.

2. Authority and signer checks

One of Anchor's biggest strengths is that it turns many security checks into declarative constraints.

Typed accounts, Signer, has_one, seeds, and bump allow you to express who can access an instruction and which accounts are valid directly in the account context. Anchor then verifies those constraints before your instruction handler runs, reducing the amount of manual validation you need to write yourself.

That doesn't mean authorization becomes automatic. Anchor can enforce the constraints you declare, but it's still your responsibility to declare the right ones.

Checklist

Every privileged instruction requires the expected signer.
Authority relationships are enforced with has_one or explicit constraints.
PDA accounts use the correct seeds and bump constraints.
Never trust a public key alone, verify that the required signer is actually present.

3. Think like an attacker

Instead of asking "Does this instruction work?", I started asking: How would I try to break it?. That single change produced much better tests.

Checklist

Test wrong signers.
Test substituted accounts.
Test over-withdrawals.
Assert the exact Anchor/runtime error, not just that the transaction failed.

4. Fuzz what humans wouldn't think of

At first, I thought testing meant coming up with the right test cases myself. But there's a limit to how many cases one person can realistically think of. There are simply too many possible inputs to write tests for manually. Instead of choosing every input myself, I let the computer generate thousands of different combinations and try them against the program. Fuzzing explores that space much faster and can uncover edge cases I'd probably never think to test on my own.

Checklist

Fuzz balance changes.
Fuzz arithmetic.
Fuzz edge-case values.
Keep the fuzz tests after the bug is fixed.

5. Let Anchor help - but know its limits

Anchor protects me from an entire class of mistakes by enforcing owner validation, account discriminators, signer constraints, PDA seeds and bumps, and reinitialization checks. But it can't decide:

whether my arithmetic is correct
whether my business logic is safe
whether a CPI should happen or
whether an unchecked account should be trusted

Anchor is a powerful safety net, but it only enforces the constraints you define. Writing secure programs still means understanding what Anchor validates for you and what it doesn't.

Closing Remarks

I think about security a little differently now. It's less about writing clever defenses and more about consistently validating assumptions before your program trusts anything.

This checklist is one I'll keep coming back to before every deployment. I'm sure it isn't complete, and I expect it to grow as I learn more and build more complex programs.

If you spot something I've missed or have a security check that's become part of your own workflow, I'd love to hear it. Security checklists are living documents, and they're better when they're improved by the community.

Why Solana Programs Can Sign Without Private Keys

Elizabeth Afolabi — Thu, 23 Jul 2026 14:40:16 +0000

For a long time, I assumed every signature on Solana came from someone's wallet. That seemed obvious. If a transaction needed authorization, the owner of the account would sign it with their private key.
Then I built a program that withdrew SOL from a PDA-owned vault. The vault had no private key, yet the transfer succeeded. That forced me to rethink what "signing" actually means on Solana.

My mental model of CPIs

When I first learned about Cross-Program Invocations (CPIs), I imagined them as a way of doing familiar things programmatically. If I wanted to mint tokens, my program would somehow mint the tokens itself instead of me running CLI commands.That wasn't what was happening at all.

Instead, my program was asking another program to perform the operation. The first CPI I built transferred SOL by calling the System Program, my program never moved the SOL directly. It simply constructed the instruction, passed in the required accounts, and delegated the work to the System Program.


pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {
        let cpi_accounts = Transfer {
            from: ctx.accounts.sender.to_account_info(),
            to: ctx.accounts.recipient.to_account_info(),
        };

        let cpi_context = CpiContext::new(
            ctx.accounts.system_program.key(),
            cpi_accounts,
        );

        transfer(cpi_context, amount)?;

        Ok(())
    }

pub struct SolTransfer<'info> {
    #[account(mut)]
    pub sender: Signer<'info>,
    #[account(mut)]
    pub recipient: SystemAccount<'info>,
    pub system_program: Program<'info, System>,
}

That taught me something I hadn't appreciated before:

Solana programs don't duplicate functionality. They build on top of one another.

That design keeps programs small and composable. Instead of every program implementing the same logic, they can reuse trusted programs that already exist.

I used exactly the same idea to mint Token-2022 tokens. The destination program changed, but the pattern didn't. Instead of calling the System Program, my Anchor program called the Token-2022 program.
I took it one step further by making one Anchor program call another using declare_program!. That was when I realized something important, a CPI isn't a feature tied to one program, it's a general communication pattern. Once I understood how one program invokes another, the specific program being called became almost incidental. Whether it's the System Program, the Token-2022 program, or another Anchor program, the idea stays the same.

Authority without private keys

The biggest shift happened when I built a PDA-owned vault. The vault held SOL. Eventually, the program needed to withdraw those funds. At first, that raised an obvious question.

How can a PDA authorize a transfer if it doesn't have a private key?

That was the assumption I had been carrying until I came across with_signer().

pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
        let user_key = ctx.accounts.user.key();
        let bump = ctx.bumps.vault;
        let signer_seeds: &[&[&[u8]]] = &[&[b"vault", user_key.as_ref(), &[bump]]];

        let cpi_ctx = CpiContext::new(
            ctx.accounts.system_program.key(),
            Transfer {
                from: ctx.accounts.vault.to_account_info(),
                to: ctx.accounts.user.to_account_info(),
            },
        )
        .with_signer(signer_seeds);

        transfer(cpi_ctx, amount)?;
        Ok(())
    }

Instead of providing a private key, the program supplies the PDA's signer seeds. The Solana runtime uses those seeds and the program ID to derive the PDA again. If everything matches, the runtime temporarily recognizes that PDA as the signer for that specific Cross-Program Invocation and no private key is involved. The program isn't forging a signature, it's proving that it has the authority to act on behalf of the PDA it originally derived. That distinction completely changed how I thought about program authority.

If someone had asked me who signs transactions on Solana, my answer would have been simple: "The owner of the account."

Now I'd answer differently. Sometimes the signer is a keypair-controlled account. Sometimes the authority belongs to a Program Derived Address. The important difference is that a PDA isn't another wallet. It has no private key. Instead, the runtime verifies that the program knows the correct seeds used to derive that PDA before allowing it to authorize the CPI. The authorization comes from deterministic derivation, not from possession of a secret key.

Breaking things made the logs make sense

One of the most useful exercises this week was deliberately breaking working CPIs to understand how the runtime enforces authority.

One error I ran into was:

compose-lab
       the caller bumps the counter through a CPI:
     Error: AnchorError caused by account: tally. Error Code: ConstraintSeeds. Error Number: 2006. Error Message: A seeds constraint was violated.

Program log: Left:
FsYY6DU3FZf7j1HnpfVEAMPr1p4HJbXEdgktN4bYJjmq

Program log: Right:
AAnoAEWwp4YgADN1Svd963buvUuWyuDdrJPXaYWi55Ck

After reading it more carefully, I realized it meant that the account I passed into the instruction didn't match the PDA Anchor derived from the seeds declared in my #[derive(Accounts)] constraint. Because the derived address and the supplied account were different, Anchor rejected the instruction before any of my program logic executed.

The fix was to make sure the client and the program were deriving the PDA from the exact same seeds (and bump). Once they matched, the constraint passed and the instruction executed normally.

What I know now

A CPI isn't another type of instruction. It's one program asking another program to perform work.
Programs don't bypass authorization just because they're programs.
A PDA doesn't have a private key. It authorizes actions by proving it was derived from the correct seeds.
with_signer() doesn't create a signature. It tells the runtime how to verify the PDA's authority.
Runtime errors become much easier to understand once you know what the runtime is actually validating.

This post is part of my #100DaysOfSolana journey and covers Days 71–75.
If you've been following along, it builds on my previous post about Program Derived Addresses (PDAs) and continues the transition from understanding how programs find state to how they safely act on it.

Why Solana Programs Don't Need to Store Your Account Address

Elizabeth Afolabi — Thu, 16 Jul 2026 08:30:45 +0000

For most applications, if you generate a random identifier for a piece of data, you need to store that identifier somewhere so you can find the data again later. That's what I expected when I started learning Solana.
Instead, I discovered that Solana programs can derive the same account address whenever they need it. They don't have to store the address at all. That was the part I had been missing about Program Derived Addresses (PDAs), and it completely changed how I think about storing application state on Solana.

The mental model

When I first heard the term Program Derived Address, I assumed it simply meant "an address created by a program." That wasn't entirely wrong, but it missed the point.
A PDA isn't just an address a program creates. It's an address a program can deterministically derive from the same inputs every time.

Those inputs are:

one or more seeds
the program's ID
a bump value

As long as those inputs don't change, the derived address never changes either. The important consequence isn't how the address is generated, it's that the program never needs to remember where your data lives. If it knows the same seeds and its own program ID, it can derive the address again whenever it needs to read or update the account.

That felt very different from what I'm used to, where generating a random identifier usually means storing it somewhere before you can find the data again.

Anatomy of a derivation

Here's what creating the counter account looked like in my program:

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

Each part has a purpose.

init tells Anchor to create the account if it doesn't already exist.

payer = user specifies which wallet funds the account creation.

space reserves enough bytes to store the account data.

The interesting part is the seeds:

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

The first seed is a static identifier that tells the program what kind of account it's deriving. The second seed is dynamic; it uses the user's public key. Anchor combines these seeds with the program ID to derive a deterministic address.

That program ID is more important than I initially realized. Even if another program used the exact same seeds, it would derive a completely different PDA because its program ID is different. That means another program can't simply pretend it owns your PDA.

What about the bump?

The bump was probably the least intuitive part for me. I don't fully understand the mathematics behind it yet, but I do understand its role. Not every derived address is valid as a PDA. The runtime searches for a valid address by trying different bump values until it finds one that falls off the Ed25519 curve.

When you write: bump

Anchor automatically derives and stores the canonical bump for you, so you don't have to calculate it yourself. That's enough for me to use PDAs correctly today, even if I couldn't explain the underlying algorithm from memory.

Why the seeds matter

Changing the seeds changes the kind of application you're building. For my counter, I used:

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

Because the user's public key is part of the derivation, every wallet gets its own counter. If I removed the user key and only used:

[b"counter"]

every wallet would derive exactly the same PDA.
Sometimes that's exactly what you want. For example, a global configuration account shared by the entire application. For a personal counter, though, it would be a disaster because every user would be trying to update the same account.

That small change in the seeds completely changes the behavior of the application.

The full lifecycle and payoff

What made this week interesting wasn't just deriving a PDA, it was seeing the entire lifecycle.

First, derive the address.
Then initialize the account at that address.
Update its state through later instructions.
Finally, close the account when it's no longer needed.

Closing the account - Earlier in the challenge, I assumed the lamports used for rent were a permanent cost. Closing my first PDA taught me they aren't.

When the account is closed, its data is removed, the reserved lamports are refunded to the designated recipient, and the account is cleaned up by the network. That made rent feel much more like a refundable storage deposit than a permanent fee.

Before this week, I assumed the client would need to remember every account address it created. Now I know that isn't necessary. As long as the frontend knows the same seeds and the program ID, it can derive the same PDA whenever it needs to fetch the account. Nothing extra needs to be stored, which makes the architecture feel much cleaner. It also answered another question I had.

Since the program ID is part of the derivation, another program can't generate the same PDA just by knowing the seeds. The same inputs in a different program produce a completely different address.

What I'd tell past me

The program never stores the account address; it derives it whenever it's needed.
A PDA has no private key. It's not a wallet.
The same seeds in a different program produce a different PDA because the program ID is part of the derivation.
You don't need to fully understand the bump algorithm on day one. Understanding its purpose is enough to start building.

What's next

PDAs solved one of the biggest questions I had about state management on Solana. On the surface, they seem like a small feature. In practice, they fundamentally change how applications manage state. Instead of remembering where data lives, programs can deterministically derive its location whenever they need it. That's a very different way of thinking about application architecture, and it's one of the biggest shifts I've had since I started learning Solana.

If you're learning PDAs yourself, I'd recommend reading the official Solana PDA documentation alongside the Anchor PDA documentation. Both helped reinforce the concepts I explored this week, and the full source code for my counter program is available on GitHub.

How a Simple Counter Program Helped Me Understand Anchor's Account Model

Elizabeth Afolabi — Mon, 06 Jul 2026 21:13:58 +0000

I've spent the last few weeks using Solana programs. This week, I finally wrote one.

The program itself is simple: a counter that stores a number and the wallet authorized to update it. The interesting part wasn't the counter. It was seeing how Anchor uses account definitions to describe state, permissions, and validation before the instruction handler executes.
Here's what I learned.

The accounts struct

In a normal backend, your function gets a request and your database is just... available. You call it when you need it.

Solana doesn't work like that. Every piece of state your instruction touches has to be declared upfront, before your code runs. This is the struct that creates a new counter:

#[derive(Accounts)]
#[account(init, payer = authority, space = 8 + Counter::INIT_SPACE)]
pub counter: Account<'info, Counter>,

#[account(mut)]
pub authority: Signer<'info>,

counter is the account being created. init allocates it on-chain, payer = authority says who pays the rent, and space is how many bytes to reserve.

authority is the wallet calling the instruction. It has to sign the transaction and it has to be mutable because SOL is leaving it.

system_program is Solana's built-in program that actually creates accounts. You list it so Anchor can call it on your behalf.

When I first saw this I thought it was boilerplate. It's not. This is you telling the runtime: here is exactly what this instruction is allowed to touch, and here are the rules. The runtime validates all of it before your code runs.

The instruction handlers

Once the accounts struct validates, the handler itself is almost boring:

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 you typed access to every account you declared in the struct. You write to the fields directly. Anchor writes those changes back to the account automatically when the instruction finishes. The handler only describes what should change.

The increment handler is where things get interesting:

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(())
}

Two things worth noting here. First, checked_add instead of+= 1: if count ever hit the max value of a u64 and you used plain addition, it would silently wrap back to zero and corrupt your data. checked_add returns an error instead.

Second, and more important: notice there is no authorization check in this function body. That check lives in the accounts struct:

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

has_one = authority tells Anchor: before this handler runs, confirm that counter.authority (the field stored inside the on-chain account) matches the authority wallet being passed into this transaction. If they don't match, the transaction fails with a constraint violation before your code ever executes.

This is the Solana equivalent of the line in your backend route that says if(req.user.id !== resource.ownerId) return res.status(403). The difference is you declared it on the struct and Anchor enforces it for you. Because the constraint lives on the account definition, it's much harder to accidentally ship a handler without authorization.

Testing It

I tested everything locally with LiteSVM; an in-process Solana VM that runs your compiled program against a fresh ledger without touching devnet. Each test gets a clean slate in milliseconds.
A passing test suite only means something if it turns red when something real breaks. Here are two tests that I know are load-bearing, because I deliberately broke the program and watched them catch it.

Happy path:

#[test]
fn initialize_then_increment() {
    let mut svm = LiteSVM::new();
    // ... setup omitted for brevity

    svm.send_transaction(init_tx).unwrap();
    svm.send_transaction(inc_tx).unwrap();

    let account = svm.get_account(&counter_kp.pubkey()).unwrap();
    let parsed = counter::Counter::try_deserialize(&mut account.data.as_slice()).unwrap();
    assert_eq!(parsed.count, 1);
    assert_eq!(parsed.authority, authority.pubkey());
}

This test proves the happy path: initialization stores the correct authority, increment updates the count, and both changes persist on-chain.

Failure path:

#[test]
fn increment_fails_when_wrong_authority_signs() {
    // authority_a creates the counter
    svm.send_transaction(init_tx).expect("initialize should succeed");

    // authority_b tries to increment it
    let result = svm.send_transaction(bad_tx);
    assert!(result.is_err(), "increment should fail when signed by the wrong authority");
}

This test would fail if the has_one = authority constraint was removed. Without this test, a program that silently allows any wallet to increment anyone's counter would still look green.

Breaking things on purpose

On Day 61 I planted three bugs to prove my tests were actually doing their job. The one that surprised me most was this: I commented out the line that sets authority during initialization:

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

Because the authority field was never initialized, the has_one constraint failed immediately, and the test caught it before the program could proceed.

Error Code: ConstraintHasOne. Error Number: 2001. Error Message: A has one constraint was violated.
Program log: Left."
"Program log: 11111111111111111111111111111111",
"Program log: Right:"
"Program log: HeKXcf775y8MYdTbSSYiTSL64fHiEAoM7h6c86WV4isT",

Without the assertion on parsed.authority, this bug would have silently deployed and broken every increment call for every user whose counter got initialized after that change.

What I'd write next

The counter works, but it still has one limitation: its address is random. The next thing I want to learn is Program Derived Addresses (PDAs), which let a program deterministically derive an account address from known seeds. That means a client can always find a user's counter without storing an extra keypair.

Why Do Token-2022 Extensions Have to Be Added at Mint Creation?

Elizabeth Afolabi — Wed, 01 Jul 2026 22:50:47 +0000

On Day 31 of MLH's 100DaysofSolana, I built a Token-2022 mint with a transfer fee extension. The instructions included one sentence that I didn't think much about at the time:

"Extensions must be configured when the mint is first created; you cannot add them later."

At the time, I treated it like any other instruction in a tutorial. I assumed it was simply one of those framework-specific rules you follow without asking too many questions. So I created the mint, completed the challenge, and moved on.
But over the next few days, as I created more Token-2022 mints with different extensions, I realized this wasn't just a one-off requirement for transfer fees. Every extension had to be decided before the mint existed. If I can deploy new features to a web application later, or add a new column to a database, why can't I create a token today with transfer fees and decide next week that I also want it to earn interest?
As it turns out, the answer has less to do with Token-2022 itself and more to do with how Solana stores data.

But before I go on, a quick detour if you are new to the world of tokens and Token-2022

Tokens

A token represents a digital asset on the blockchain. It could be a stablecoin, a governance token, a loyalty point, or even an NFT. But regardless of what it represents, every token begins with a mint.

You can think of a mint as the blueprint for that token. It defines core properties such as the token's supply, decimal precision, mint authority, and the rules that govern how new tokens are issued.

Token-2022 Extensions

The original Solana Token Program provides the basic functionality most tokens need: creating tokens, minting new ones, transferring them between accounts, and burning them. But many real-world applications require additional behavior. A stablecoin might charge a transfer fee. A rewards token might earn interest over time. An NFT collection might store metadata directly on-chain.

Instead of creating a new token program for every one of these use cases, Token-2022 introduces extensions (optional features) that add new capabilities to a token mint. You choose only the extensions your application needs, whether that's transfer fees, interest-bearing balances, metadata pointers, permanent delegates, or something else.

Now that that's cleared, let's circle back to the question:

If they're just optional features... why can't I enable one later?

If you've ever enabled authentication, payments, or file uploads in a web application, you've already worked with the idea of adding capabilities to a system over time. That's why Solana's requirement to choose certain token capabilities before the token even exists feels so unusual.

The Missing Piece

As I continued through the challenge, I created different Token-2022 mints with different extensions. Then, on Day 39, instead of creating another token, we inspected the ones we'd already built by running the token display command:

spl-token display $MINT --program-2022


SPL Token Mint
---
Extensions
------------
Transfer Fee
Metadata Pointer
Metadata

I repeated this for three different tokens and compared their account sizes and rent costs.

Mint address	Extensions enabled	Account data size (bytes)	Rent cost (SOL)	Key authorities
`Ay6J...qTwGkDp`	Interest-bearing	222	0.002436	Mint authority: `EHAj6...XQgj` Freeze authority: None Rate authority: `EHAj6...XQgj`
`5CyH...vwwSx`	Interest-bearing Transfer fees Metadata Pointer Metadata	599	0.00505992	Mint authority: `EHAj6...XQgj` Freeze authority: None Rate authority: `EHAj6...XQgj` Transfer fee config authority: `EHAj6...XQgj` Transfer fee withdrawal authority: `EHAj6...XQgj`
`Cc1E...XvmH`	Default Account State (Frozen)	171	0.00208104	Mint authority: `EHAj6...XQgj` Freeze authority: `EHAj6...XQgj`

One thing immediately stood out, the more extensions a mint had, the larger the account became.

Why Extensions Must Be Added at Creation

The answer lies in how Solana stores data. On Solana, everything is stored in accounts. Unlike a typical database where storage can grow as you add more data, Solana accounts are created with a fixed amount of space. Once an account is initialized, that allocated space doesn't automatically expand.

That means when you create a Token-2022 mint, Solana isn't just creating a token, it is allocating enough storage to hold everything that mint will ever need. Every extension you enable becomes part of that mint account, it isn't just a switch that turns a feature on or off. It stores its own configuration data inside the mint account.

For example, a transfer fee extension needs to keep track of information such as the fee basis points, the maximum fee, and the authorities responsible for updating or withdrawing fees. A metadata extension stores information about where the token's metadata lives. Since each extension carries its own data, every additional capability increases the amount of storage the mint account requires and Solana needs to know exactly how much space to allocate before the mint exists. The process looks something like this:

Choose the extensions your token needs
│
▼
Calculate the total account size
│
▼
Allocate storage for the mint account
│
▼
Calculate the rent-exempt balance
│
▼
Create the mint

Now, that instruction from Day 31 stopped sounding like a rule I had to memorize, it became the natural consequence of Solana's account model. I now know that I can't add an extension later because there isn't extra space waiting to be used. Adding another extension later would require the mint account to grow, and Solana accounts don't grow like rows in a relational database.

Coming from Web2, I was used to thinking of software as something that evolves over time. If I needed another feature, I'd update the schema or deploy another version of the application. Token-2022 challenged that mental model. On Solana, you're not just defining what your token does today; you're deciding how much space it will ever need before it's even created. A short comparison like this helps to put it more into perspective.

Web2	Solana
Add a database column later	Allocate account space up front
Deploy new application features	Decide mint capabilities before creation
Storage grows as needed	Storage is fixed at account creation

Conclusion

Looking back, that sentence from Day 31 wasn’t just a rule to follow, it was a constraint that revealed how Token-2022 is designed. At first, it felt like an arbitrary limitation: why force developers to decide everything up front? But after working through multiple mints and eventually inspecting them on-chain, the reason became clear.

Token-2022 isn’t designed around “features you can turn on later.” It’s designed around state that must be fully allocated before it exists. Every extension becomes part of the mint’s storage footprint from the very beginning, which is why the system forces you to define its shape at creation time.

What changed for me wasn’t just my understanding of Token-2022, it was how I think about building on Solana. On Solana, you don’t evolve accounts over time; you design them before they exist. That’s a very different way of thinking compared to Web2, and one of the most valuable lessons I took away from Epoch 2 of 100 Days of Solana.

If you've had a similar "Why does Solana work this way?" moment while learning, I'd love to hear about it in the comments.

Reading Token Configuration on Solana: Why the Mint Became My Source of Truth

Elizabeth Afolabi — Tue, 23 Jun 2026 16:59:47 +0000

Early in my Solana journey, most of my attention was on commands. Which flag do I need? Which address goes here? Which extension am I enabling?. This week, I realized those questions matter less than I thought. The commands are temporary. The mint configuration is what survives.

From commands to configuration

Over the past few weeks, I've been working with Token-2022 extensions such as transfer fees, interest-bearing balances, metadata, and non-transferable tokens. At first, building these assets felt command-heavy. Every operation required long mint addresses, token account addresses, and extension flags.

One small workflow improvement changed that.

export MINT=<mint-address> 
export MY_TA=<token-account>

Instead of repeatedly pasting addresses into every command, I stored them as shell variables and reused them throughout the session.
The immediate benefit was cleaner commands and fewer mistakes. But it also shifted my attention away from the mechanics of running commands and toward the asset itself. I stopped thinking about how I created a token and started thinking about how the token was configured.

The mint is the source of truth

The command I used most this week wasn't a creation command.

It was:

spl-token display $MINT

This command became my primary inspection tool. Rather than relying on memory or searching through old terminal history, I could read the mint directly and verify its configuration.

From a single output, I could see:

Transfer fee settings
Interest-bearing configuration
Authorities
Metadata
Extension information
Non-transferable restrictions

As a Web2 developer, this felt surprisingly familiar. When debugging an application, I often look for the configuration that defines how the system behaves. On Solana, the mint serves a similar role. It contains the configuration that determines what a token can do.

Token behavior lives in configuration

One example that reinforced this idea was an interest-bearing token I had created earlier. My original expectation was simple: if a token earns interest, the balance stored in the account should increase over time. That's not what happens.

The raw amount stored in the token account remains unchanged. Instead, the mint stores the interest-rate configuration, and wallets calculate the interest-adjusted balance when displaying it.

In other words, the behavior comes from the mint's configuration rather than from continuously updating token accounts. That distinction is easy to miss if you're only looking at wallet balances. It becomes obvious when you inspect the mint itself. The token account stores the amount, the mint defines how that amount should be interpreted.

Tooling can hide complexity, but not configuration

Another interesting moment came when creating a new non-transferable token.
Earlier in the challenge, configuring Token-2022 assets often meant specifying programs and extensions manually. By Day 54, I was using simpler commands and extension flags such as:

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

The CLI was doing more of the work for me.

From a developer experience perspective, this is great. The tooling becomes easier to use while still producing the same underlying result. What stood out, though, was that the mint configuration remained the important part. The command could change, the flags could change.
Future versions of the tooling might simplify the workflow even further. But once the mint is created, its configuration is what determines how the asset behaves.

Key Takeaway

This week changed how I think about verification on Solana.
Wallets, explorers, and developers are all reading the same on-chain configuration. If I want to know whether a token charges transfer fees, accrues interest, or can be transferred at all, I don't need a private API or application dashboard. I can inspect the mint directly.

That's the shift that stuck with me. The commands that created the asset are temporary, the token's configuration is permanent and on Solana, the mint is often the best place to understand what an asset actually is.

This post is part of #100DaysOfSolana. Follow along as I continue exploring how assets and applications are built on Solana.

Understanding Solana NFTs as a Web2 Developer: More Than Just JPEGs

Elizabeth Afolabi — Sat, 13 Jun 2026 11:37:41 +0000

I knew NFT stood for non-fungible token, meaning a unique token that isn't interchangeable like a currency. Beyond that, I mostly associated NFTs with digital images and ownership.

After spending a week creating NFTs, attaching metadata, organizing them into collections, auditing them on-chain, and updating them live on devnet, I came away with a different mental model. What changed wasn't my understanding of ownership.
It was my understanding of structure.

An NFT is still a token

The first thing I learned is that NFTs are not a separate asset type on Solana.

Under the hood, the NFT I created used the same SPL token model I had been working with throughout the Token-2022 challenges.

There was still:

a mint account
a token account
an owner wallet

The difference was entirely in the configuration. The NFT mint was created with:

a supply of 1
0 decimals
the mint authority removed after minting

Once the mint authority was disabled, no additional tokens could ever be created. That permanently locked the supply at one.

What appears to be a completely different asset category is actually the same token architecture configured with different rules.

spl-token create-token --decimals 0

spl-token mint <NFT_MINT_ADDRESS> 1

spl-token authorize <NFT_MINT_ADDRESS> mint --disable

Metadata gives the asset context

A token with a supply of one is unique, but uniqueness alone does not explain what the asset represents. To make the NFT meaningful, I attached metadata using the Metadata Extension which included a name, a symbol and URI.
The URI points to a JSON file containing additional information such as the image, description, and custom attributes.

One detail I hadn't considered before is why the URI exists in the first place. Storing images and large metadata files directly on-chain would increase account size significantly, making storage more expensive. Instead, the NFT stores a reference to the metadata through a URI, while the larger files remain off-chain.

When a wallet displays an NFT, it reads the metadata stored on-chain, follows the URI, retrieves the JSON file, and then renders the asset. In other words, the NFT stores the reference, not the image itself.

Collections introduce relationships

Creating a collection introduced another layer of structure. Using the Group and Member extensions, I created a collection NFT and linked multiple NFTs to it.

The simplest way I can describe it from a Web2 perspective is as a parent-child relationship.

The collection acts as the parent, the individual NFTs act as members that reference that parent. This reminded me of how related records are connected in a database. The relationship is not implied by naming conventions or application logic. It is stored directly on-chain. That means anyone can independently verify whether an NFT belongs to a collection.

# Create a collection mint
spl-token create-token --enable-group

# Create an NFT and attach it to the collection
spl-token create-token --group <COLLECTION_MINT>

Verifying the relationship on-chain

After creating the collection, I wanted to see how that relationship was actually represented. Using spl-token display and Solana Explorer, I inspected both the collection mint and the NFT mints.

The important detail was that each NFT contained a Group reference pointing back to the collection mint. That meant collection membership wasn't just something maintained by a marketplace or wallet interface. It was part of the NFT's on-chain configuration and could be verified by anyone reading the account data.

This was one of the more useful exercises of the week because it reinforced a recurring theme in Solana development:

don't assume something exists—inspect the account and verify it.

Updating metadata after minting

One thing I tested next was modifying the NFT after it had already been created.
Using the Token-2022 metadata extension, I:

changed the NFT name
added and removed custom metadata fields
updated the URI to point to a different metadata file

The updates appeared immediately on-chain.

The image, however, did not always update immediately. The reason is that these are two different layers of data.

The name, symbol, URI, and metadata fields live on-chain.
The image is stored off-chain and retrieved through the URI.

Many wallets cache metadata responses, which means visual updates can take longer to appear even though the on-chain change has already been confirmed. This was a useful reminder that an NFT is often a combination of on-chain state and off-chain content.

What changed in my understanding

I started the arc thinking of NFTs primarily in terms of uniqueness and ownership. I finished thinking about configuration, metadata, and relationships.

The NFT itself was not the most interesting part.

The more interesting discovery was that NFTs on Solana are built from the same foundations as every other asset I've worked with so far: mints, token accounts, metadata, and program-enforced rules. The image is what users see, the structure behind it is what defines the asset.

This post is part of #100DaysOfSolana. Follow along as I continue exploring how assets are built on Solana.

Building a Soulbound Credential on Solana with Token-2022

Elizabeth Afolabi — Mon, 01 Jun 2026 12:53:27 +0000

How combining Non-Transferable and Permanent Delegate extensions changed my understanding of digital ownership on Solana.

Imagine earning a high rank in an online game.

You can use it. You can benefit from it. Other players can see it. But you cannot transfer that rank to someone else.

If you break the game's rules, the game company can revoke it. And if the game gets acquired by another company, authority over that rank can be handed over to a new administrator.

That was the closest mental model I found for understanding one of the most interesting things I built this week on Solana: a credential token using Token-2022 extensions.

What are Token Extensions?

One thing I've learned during this phase of the challenge is that Token-2022 is not just about creating tokens.

It allows you to define behaviors directly at the token level through extensions.

Instead of relying on application logic to enforce rules, the token program itself can enforce them.

For this experiment, I combined two extensions:

Non-Transferable — prevents ownership from being transferred to another wallet.
Permanent Delegate — gives a designated authority the ability to manage the token even after it has been issued. Individually, those are useful.

Together, they create something that behaves less like a currency and more like a credential.

The Transfer That Was Supposed to Fail

After creating the token, I tried transferring it.

spl-token transfer Gn5PZzwDENvpQESaFwgVqzCUFba5sSka59iLtjFTYNvz 1 $THIRD_PARTY \
  --owner ~/recipient-wallet.json \
  --fee-payer ~/.config/solana/id.json \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --fund-recipient --allow-unfunded-recipient

The result:

Recipient: ErYcpQYcpdoaaiufrB3MqQE2QaVEhoACZGcssppszPpY

Recipient Token Account:
8CvyoKt11UbkWYRVXey6UKK2gqQcvVvbh9Lv3crzo8C3

Funding ATA:
8Cvyokt11UbkWYRVXey6UKK2qqQcvVvbh9LV3crz0803

Status:
❌ Transaction failed during simulation

Error:
Transfer is disabled for this mint (Token-2022 restriction)

What I liked about this failure is that it wasn't unexpected.
The token holder owned the token account. Normally, that would be enough. But because the token was created with the Non-Transferable extension, the transfer was rejected by the token program itself.

There was no application checking permissions, no backend deciding whether the action was allowed.

The restriction lived inside the asset. That was the moment the idea really clicked for me.

The Part That Surprised Me

The failed transfer wasn't the surprising part, the Permanent Delegate extension was.

While experimenting, I discovered that the delegate authority itself could be reassigned. I tried delegating the authority to another account

spl-token authorize \
  Gn5PZzwDENvpQESaFwgVqzCUFba5sSka59iLtjFTYNvz \
  permanent-delegate 12ntWdec88nfRq5uaaxkEBy4EtdQjXuD8ywWzxDjCEM2  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Conceptually, that means the authority responsible for managing a credential can change over time.

For example:

A company issues employee credentials.
The company gets acquired.
Authority over those credentials is transferred to a new administrator.

The credentials remain valid, the people holding them do not change but the entity responsible for managing them can.

That felt much more flexible than I initially expected.

The Part That Confused Me

I'll be honest: part of me kept thinking this felt surprisingly centralized.

A credential holder cannot transfer the token.
A delegate can revoke it.
Authority can even be reassigned.

At first glance, that seems to clash with the idea of decentralization. What helped me reconcile that is realizing that not every asset is trying to solve the same problem.

Money, governance tokens, certificates, memberships, and identity credentials all have different requirements.

In some cases, transferability is the feature. In others, transferability defeats the entire purpose.

A certification would lose its meaning if anyone could sell it.

What Clicked

Earlier in the week, I experimented with other Token-2022 extensions, including:

transfer fees
interest-bearing rates
metadata

What finally made sense was seeing multiple extensions work together inside a single asset.

The token wasn't just representing value anymore, it was representing rules, permissions, and relationships.

That's a very different way of thinking about assets.

Instead of asking:

What does this token represent?

I started asking:

What behaviors does this token enforce?

Final Thoughts

Before this week, I mostly thought of tokens as things that hold value and move between wallets.

Building a credential token challenged that assumption.

The combination of Non-Transferable and Permanent Delegate extensions showed me that tokens can represent much more than currency. They can represent memberships, achievements, certifications, and other forms of ownership where movement is not the goal.

If you want to explore these concepts further, I recommend reading the official Token-2022 Extensions documentation and experimenting with a few combinations yourself.

The most interesting part isn't any single extension.

It's seeing what happens when you start combining them.

Why One Solana Token Needs Three Different Addresses

Elizabeth Afolabi — Sun, 24 May 2026 12:06:08 +0000

If you’re new to Solana, one of the most confusing things about SPL tokens is why a single token interaction can involve multiple addresses.
This post breaks down the difference between mint addresses, wallet addresses, and token accounts, and why understanding that distinction makes the Solana CLI suddenly start making sense.

When I first started working with SPL tokens, I kept running into the same problem. Every action seemed to require a different address. I wasn’t just dealing with “a token.”
I was dealing with a mint address, a wallet address and a token account address.
But the more I used the CLI, the more I realized something:

I wasn’t interacting with one system. I was interacting with three different responsibilities.

Where the Address Model Starts Becoming Important

What made things confusing was that different commands kept expecting different kinds of addresses.

spl-token create-token

This gives you a mint address.

Then I would move to:

spl-token create-account <MINT_ADDRESS>

Now I have a token account.

And finally:

spl-token transfer <MINT_ADDRESS> 100 <RECIPIENT_WALLET_ADDRESS>

This is where things started to feel inconsistent.

Why is the mint address used here?
Why is the wallet used here?
And where exactly is the token actually stored?

The key idea I was missing

What helped everything click was this:

A wallet does not hold tokens on Solana.

That sounds simple, but it changes everything.
Because if wallets don’t hold tokens… then something else must. That “something else” is the token account.

The three-address model

Once I mapped everything properly, the system became much clearer.

1.Mint Address — the token identity

This is created when you run:

spl-token create-token

The mint defines what the token is, its rules and its supply. It doesn’t hold tokens, it defines the token itself.

2.Wallet Address — the owner identity

This is your actual account (keypair). It:

signs transactions
authorizes actions
represents the user

But it does not store token balances, it only provides authority.

3.Token Account — the balance container

This is where things actually live.

Created using:

spl-token create-account <MINT_ADDRESS>

A token account stores:

balance
association to one mint
ownership by a wallet

So the real structure is:

one wallet → many token accounts → one per mint relationship

Why balance requires BOTH wallet and mint

This was one of the most confusing parts for me:

spl-token balance --owner <WALLET_ADDRESS> <MINT_ADDRESS>

Why both?

Because:

wallet = who owns the tokens
mint = which token we are talking about

A wallet can hold:

USDC
custom tokens
NFTs
multiple SPL tokens

So the CLI needs both inputs to find the correct token account. Under the hood, it:

derives the associated token account (ATA) for that wallet + mint pair
then reads the balance from it

That’s why both are required.
Associated Token Accounts are derived automatically from a wallet + mint pair using Solana’s ATA standard.

Why transfers feel “indirect”

This command made more sense after understanding the model:

spl-token transfer <MINT_ADDRESS> 100 <RECIPIENT_WALLET_ADDRESS> --fund-recipient

The key detail is:

tokens are not sent to wallets directly

They are sent to token accounts. So what actually happens is:

system checks if recipient has a token account for this mint
if not, --fund-recipient creates it
tokens are then transferred into that account

That’s why the wallet address is enough, but only because the system can derive the token account from it.

Token-2022 and programmable assets

One of the most interesting parts of this journey was Token-2022.

Unlike standard SPL tokens, Token-2022 introduces extensions that add behavior directly at the protocol level.
Solana’s Token Extensions documentation explains how these extensions allow tokens to enforce behavior directly at the protocol level.

Examples include transfer fees, non-transferable tokens, metadata extensions, custom rules enforced by the token program itself

What stood out to me is this:

These rules must be defined when the mint is created. They cannot be added later.

That changes how I think about tokens entirely. They are no longer just balances. They are programmable assets.

What actually changed for me

At first, the CLI felt inconsistent because I was thinking in terms of:

“a token”
“a wallet”
“a transfer”

But Solana doesn’t structure it that way. Instead, it separates responsibilities:

mint => defines what exists
wallet => defines who controls actions
token account => defines what is owned

Once I saw that pattern, the system stopped feeling fragmented. It started feeling intentional, even elegant.

The biggest shift for me was realizing this:

Solana doesn’t store tokens in wallets. It stores relationships between identities, assets, and balances.

Now that the address model finally makes sense to me, I’m starting to see Token-2022 less as “tokens with extra features” and more as programmable assets with rules built directly into the protocol.

I’m curious to see how far that model can go as the challenge continues.

Understanding Solana’s Account Model From a Web2 Perspective

Elizabeth Afolabi — Tue, 19 May 2026 22:27:50 +0000

In a previous article I posted on my #100daysofsolana journey, I wrote about how everything on Solana is an account. I spoke briefly about the difference between wallet accounts and program accounts. You can read the article here

In this article, we will go more in depth because I now have more knowledge after inspecting various accounts over the past few days.

Everything is an account. But not all accounts are the same

Unlike Ethereum, which separates wallet accounts from smart contracts, Solana uses the same model for all accounts. They all have the same five fields, but what differs is the meaning and value of those fields.

The Account's Five Fields

Every account on the Solana network has these five fields. Here's what they actually mean:

1.Lamports
This is the field that carries information on how much the account holds. Solana stores balances in lamports.

1 SOL = 1 billion lamports.

Sometimes, depending on how you are viewing the account structure, this field shows up as Balance with the value in SOL. Just know it's showing the same thing in a more human readable format.

2.Data
The data field refers to the storage space the account occupies. In Web2, this is similar to a database entry. It is stored as a raw byte array.
For example, the Token Program's data field looks like this in the raw output:

0000: 02 00 00 00 27 f1 90 b1 e8 ca df f9 f8 fc 45 cb
0010: d3 af 98 b8 8e 5f ac 42 0d 97 dd 37 ce 71 4c 44

In a more readable format, it shows up as `Length: 36 (0x24) bytes.

Wallet accounts have an empty or zero data field because they are simple SOL holders. They don't store anything beyond a balance. But program accounts, token accounts, and NFTs all have data because they store state.

This is also where something important happens:
Programs on Solana don't store their own state inside themselves. A program's executable code lives in one account, and the data it reads or writes lives in completely separate accounts. So when you see a program account with only 36 bytes, that's not where the user balances are, those live in their own individual accounts that the program manages externally.

3.Owner
This field tells us which program controls and is able to modify the account. Wallet accounts are owned by the System Program. Program accounts are typically owned by the BPF Loader. Built-in system programs, like the System Program itself, are owned by the Native Loader.
Solana has a security model in place such that a program can only write to the accounts it owns.

4.Executable
This is a boolean field that returns true or false. It tells us whether the account has a set of instructions written in code that it can run.
Program accounts have executable: true because they run programmed instructions. Other accounts like wallets and token accounts have executable: false because they don't run code, they just hold state.

5.Rent Epoch
Solana has a rent system; a cost for storing data on-chain. The rent epoch field was originally designed to show when the next rent would be deducted from the balance. Currently, accounts have been made rent-exempt by being funded with enough SOL upfront, which made this field less important.

How to think about it as a Web2 developer

We can compare Solana's account model to how a React app makes calls to a backend REST API in Web2. Stay with me.

The Solana program is like a backend API, and accounts are the databases the API reads or writes to. The frontend sends a request, and the backend(the program), executes what changes need to happen. On Solana, that request is called a transaction. Just like a REST API hits a POST or PUT endpoint, a Solana transaction invokes a specific program instruction.

The main thing to remember is that neither system stores information inside the request handler. Instead, data is stored separately, in a database in Web2, or in accounts on Solana. These accounts are like rows in a database. Each one holds some information about the application, identified by a special key.

So when you look at a Solana account, you can think of it like a record in a database:

The public key is like the identifier for the record
The data field is the actual information in the record
The lamports field is like a balance or credit attached to the record
The owner field is the service that is allowed to make changes to the record

Solana's ownership rules

Like I mentioned earlier, in Solana only the owner of an account can modify it. This sounds straightforward, but let's drive it home from both a Web2 and Solana perspective.

Only the owner can modify an account, but anyone can credit it. Meaning anyone can send SOL to any account. This is the security model Solana enforces at the protocol level.

Just like in a REST API system, only the backend service that owns a database table is allowed to modify the rows. Other services can request to read the data, but they can't write to it unless they're authorized. Solana enforces the same idea, only the owner program is allowed to mutate the account's data.

So if a token account is owned by the Token Program, no other program can directly edit its balance. They must go through the Token Program's instructions, just like a frontend must go through the correct API endpoint instead of writing directly to the database.

What are rent exemptions?

I mentioned that recently, accounts have been made rent-exempt. What does that actually mean?

In Solana, every account is like data stored on-chain, and you have to pay some amount to keep it there. That's rent. For a basic account with no extra data, it's roughly 0.00089 SOL.
But it's not a fixed amount, it's calculated based on the size of the data an account holds using the rent calculation formula.

In older versions of the model, this rent was collected periodically. When an account didn't have enough lamports, the network would reclaim it.But now, instead of paying periodically, you just fund the account with enough SOL to meet the minimum balance threshold. That makes it permanently rent-exempt. The SOL isn't spent, it's held as a deposit. Close the account, and you get it back.

You can check the rent exemption amount two ways:

Using the RPC method: getMinimumBalanceForRentExemption

Or through the CLI:

solana rent <DATA_SIZE>

Conclusion

When I started this journey, fields like owner, executable, and rent epoch were a bit abstract to me. I was staring at output I couldn't read.

Now I can look at any account on Solana and tell you exactly what it is and what it does just from those five fields. That's the account model, and if you've followed along to this point, you can too.

Everything on Solana is an account. What differs is just the configuration. That's it. That's the whole foundation.
Once that lands, a lot of other Solana concepts start making sense on their own.

If you want to make it stick, don't just take my word for it. Run this yourself:

solana account $(solana adress)

Then try it on the Token Program, then the System Program. See the same five fields show up every time. That's the moment it clicks.

What Failed Transactions Taught Me About Solana

Elizabeth Afolabi — Mon, 11 May 2026 17:44:10 +0000

A few days ago, Solana transactions still felt abstract to me.

I understood the general idea:
sign a transaction -> send it to the network -> it gets processed.

But during this phase of the challenge, things started becoming more concrete.

Especially when I began inspecting transaction confirmations, experimenting with transfer tooling, and intentionally triggering failed transactions.

That’s when Solana stopped feeling like “crypto magic” and started feeling more like engineering.

My Initial Mental Model

At first, I thought of transactions almost like simple requests:

send SOL from A -> B

And that was basically it.

But after exploring transaction anatomy more deeply, I realized a Solana transaction is much more structured than that.

It’s:

a signed request
containing instructions
executed by programs
against accounts
processed by a distributed validator network

The official Solana transaction docs also helped clarify how signatures, instructions, and accounts are structured internally:
https://solana.com/docs/core/transactions

That mental shift changed how I started looking at the system.

One thing that made transactions easier to understand was comparing them to requests in traditional applications.

Not exactly the same, but close enough to create a mental bridge.

You construct a request, send it to a distributed network, wait for processing, and eventually receive confirmation back.

But unlike a normal API request:

transactions require signatures
they expire after some time
validators participate in confirming them
and failure can still cost money

Failed Transactions Changed My Perspective

I intentionally triggered an insufficient funds error expecting the transaction to simply reject without consequences.

Instead, I learned something important:

failed transactions can still consume fees.

That caught me off guard.

Even though the transfer failed, validators still processed the transaction and performed work, so fees were still deducted.

That completely changed how I thought about blockchain transactions.

In most frontend workflows, a failed action usually just returns an error.

Here, failure still has a cost.

And suddenly concepts like validation, simulation, balance checks and transaction design started feeling much more important.

Confirmation States Made More Sense Than I Expected

Another concept that stood out to me was transaction confirmation.

I learned that transactions move through stages like:

Processed
Confirmed
Finalized

At first, these looked like simple status labels.

But they actually represent increasing confidence from the network.

A validator first processes the transaction, then the network reaches supermajority agreement.

Then enough blocks are added afterward that reversal becomes practically impossible.

I still don’t fully understand concepts like polling and finality yet, but this was the first time transaction processing started feeling like a real distributed system instead of just a black box.

One Detail That Really Stuck With Me

Another thing that genuinely surprised me was learning this:

Creating a wallet does not automatically create an on-chain account.

The address exists immediately because it’s derived from a keypair.

But the actual account only exists on-chain once it’s funded.

That distinction felt subtle at first, but it changed how I think about accounts on Solana.

Storage and state feel much more explicit here than I initially expected.

What Changed for Me

The more I explored transactions, the less Solana felt like “just sending crypto.”

It started feeling more like interacting with a distributed system with strict rules around state, validation, execution and confirmation.

I also became much more aware of the complexity underneath even simple transfers.

Before this, a transaction felt like:

click send and wait

Now I see:

validators processing requests
confirmation stages
execution rules
signatures
fees
and failure handling

all happening underneath something that initially looked simple.

I still don’t fully understand every part of the system yet, but transactions no longer feel abstract to me anymore.

And honestly, that’s probably the biggest shift from this week.

Day 16 of my 100 Days of Solana

Elizabeth Afolabi — Thu, 07 May 2026 02:11:51 +0000

Today I sent a SOL transfer on devnet and inspected the transaction on Solana Explorer.

One thing that really stood out to me was the

--allow-unfunded-recipient flag.

It helped me understand that on Solana, creating a wallet address does not automatically mean an on-chain account exists.

The address exists immediately after generating a keypair, but the actual account only exists once it’s funded.

So in this transaction, I wasn’t just sending SOL; the network was also creating the recipient account on-chain.

Very different from Ethereum’s “just send” model.