DEV Community: Matthew Revell

# Arc 9 Catch-Up: Writing Your First Solana Program

Matthew Revell — Wed, 24 Jun 2026 12:49:27 +0000

With Arc 9 of 100 Days of Solana, we enter the third big phase — or Epoch, as we call them — of the learning program.

And we make a pretty big shift.

Up until now, we have been getting hands-on with Solana mostly through JavaScript. We have created wallets, sent transactions, minted tokens, configured Token-2022 extensions, and inspected on-chain state from the client side.

Arc 9 changes the angle.

Rust is the native language of Solana programs, and this arc is our first step into writing Solana logic ourselves.

The program we built was deliberately simple: a counter.

Initialize it. Store who owns it. Increment it. Reject anyone else who tries.

This was a great way to learn a little about the shape of Solana program dev:

instructions as program entry points
accounts as state
account constraints as guardrails
tests that prove both success and failure paths

So, let's get into the details.

Anchor gives us a framework for Solana programs

In Web2, we use frameworks like Next.js, Ruby on Rails, Django, and .NET.

The principal Solana equivalent is Anchor.

Like its Web2 equivalents, Anchor gives us a project structure, a way to define instructions, a way to describe the accounts each instruction needs, and a testing setup that makes local development much more approachable.

And that really helps when we're taking our first steps with Rust development for Solana. We don't need to be learning low-level details at this stage. Instead, we are trying to get a working program in place, understand its shape, and build enough confidence to change it.

A counter is enough to learn the shape

The first program we built was a counter because it gives us just enough state and behavior to make the Solana program model visible:

create an account
store some data in it
update that data later
restrict who is allowed to update it
write tests that prove those rules work

The program starts with an initialize instruction.

That instruction creates a new counter account, stores the wallet that created it as the authority, and sets the count to zero.

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;

    counter.authority = ctx.accounts.authority.key();
    counter.count = 0;

    Ok(())
}

Even if you're brand new to Rust, you can probably get the idea of what's happening here.

We get the counter account from ctx.accounts.counter, store the authority's public key, set the count to 0, and return Ok(()).

But there is a lot happening around that small handler.

That setup lives in the 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>,
}

This is one of the first big Anchor lessons.

The instruction handler tells us what the program does.

The accounts struct tells us what accounts the instruction needs, what permissions they need, and what checks Anchor should run before the handler executes.

In this case, it says:

create a new counter account
use authority to pay for it
make sure authority signed the transaction
allocate enough space for the account data
use the System Program to create the account

The handler is short because the accounts struct is doing a lot of the setup work.

That is the shape we keep coming back to in Arc 9: instruction logic in one place, account requirements in another.

The account is the program's state

The counter data itself lives in a custom account.

#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub authority: Pubkey,
    pub count: u64,
}

This is the first bit that feels different if you are coming from normal web development.

In a Web2 app, you might expect this state to live in a database row. You might have a counters table with an owner_id column and a count column.

In this program, the state lives in a Solana account.

The count field stores the number.

The authority field stores the wallet that is allowed to update it.

That second field is what makes the example useful. Without it, anyone could increment the counter. With it, the program has a rule it can check later.

So even though the counter is simple, it already has the ingredients of a real program:

stored state
ownership
an update path
a rule about who is allowed to use that path

Incrementing the counter introduces authorization

Once the counter exists, the next step is to update it.

That happens through an increment instruction.

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

Again, the handler itself is easy enough to follow.

It gets the counter account, adds one to the count, and returns Ok(()).

The checked_add(1) part is worth noticing. Rather than adding blindly, it checks for overflow and returns an error if the number cannot safely be increased.

But the more important part of this instruction is not the arithmetic.

It is the account constraint.

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

    pub authority: Signer<'info>,
}

The key line is this:

#[account(mut, has_one = authority)]

mut says the counter account can be changed.

has_one = authority says the authority field stored in the counter account must match the wallet signing this instruction.

That is the rule that stops one wallet from incrementing someone else's counter.

In a web app, we might write that as an authorization check inside a controller or route handler:

if counter.owner_id != current_user.id:
    reject the request

In Anchor, that rule is declared on the account instead.

So the instruction has two parts working together:

the handler says what happens when the instruction is allowed to run
the accounts struct says what must be true before it runs

That is why this tiny counter example is useful. It is not just changing a number. It is changing a number only when the right signer is present.

LiteSVM makes the tests feel like normal development

Once we had initialize and increment, we needed to prove they worked together.

That is where LiteSVM came in.

LiteSVM lets us run the program locally in an in-process Solana environment. We do not need to deploy to devnet, request SOL, wait for confirmations, or debug against a remote cluster.

For this arc, that was exactly what we needed.

We could build the program, run the tests, change the code, and run the tests again.

anchor build
cargo test -p counter -- --nocapture

The first useful test followed the happy path:

create a local Solana test environment
load the compiled counter program
create a counter account
call initialize
call increment
read the counter account back
check that the count is now 1

That test matters because it is not just calling a Rust function directly.

It sends transactions to the program.

The program receives accounts.

The account data changes.

Then the test reads the account back and checks what actually happened.

So even though the test runs locally, it still teaches the right execution model.

That is the main value of LiteSVM here: it gives us a fast feedback loop without pretending that Solana programs work like ordinary local functions.

The happy path is not enough

At this point, the program worked.

We could initialize a counter. We could increment it. We could read the account back and check that the count was 1.

That is a good start, but it only proves the program works when everything is used correctly.

It does not prove the program refuses to do the wrong thing.

That matters because Solana programs are public. Anyone can call them. Anyone can try different accounts, different signers, and different transaction shapes.

So the next test was more interesting:

wallet A creates the counter
wallet B tries to increment it
the program rejects the transaction

That test proves the authority rule is actually doing something.

The important line was still this:

#[account(mut, has_one = authority)]

The happy-path test proves the right wallet can increment the counter.

The failure test proves the wrong wallet cannot.

Without that second test, we could remove has_one = authority and the happy-path test would still pass.

That is the trap Arc 9 was trying to show us.

A green test suite is not enough if it only checks the path where everything goes right.

Breaking the program proved the tests mattered

The best part of the arc was breaking the program on purpose.

That might sound strange, but it is a useful habit.

Once the tests were passing, we made small changes that should have broken the program, then checked whether the tests caught them.

First, we removed the authorization rule.

#[account(mut)]
pub counter: Account<'info, Counter>,

Now the counter was still mutable, but Anchor was no longer checking that the signer matched the stored authority.

That is exactly the kind of bug the wrong-wallet test should catch.

And it did.

Then we changed the arithmetic so the counter added 2 instead of 1.

The transaction still succeeded. Nothing crashed. But the stored value was wrong, so the happy-path assertion caught it.

That is a different kind of bug.

The program runs, but writes the wrong state.

Finally, we broke initialization by not storing the authority.

The initialize instruction still looked like it worked. The account was created. The count was set to zero.

But the next instruction failed, because the program later tried to check an authority value that had never been stored correctly.

That was probably the most useful debugging lesson in the arc.

In Solana programs, one instruction might write state and another instruction might validate that state later.

So the error does not always appear where the bug was introduced.

Sometimes you have to work backwards:

which account failed validation?
which field was wrong?
which instruction wrote that field?
what did the account actually store?

The counter example was small, but the lesson scales.

If you can understand that pattern here, you are better prepared for real programs later.

What Arc 9 taught us

Arc 9 was not really about building a counter.

The counter was just the smallest useful program for learning the shape of Anchor development.

By the end of the arc, we had seen how to:

scaffold a Solana program with Anchor
write instructions in Rust
create and store data in an account
use an accounts struct to describe what an instruction needs
protect state with an authority rule
test real transactions locally with LiteSVM
write both happy-path and failure-path tests
break the program on purpose to prove the tests were meaningful

That is a meaningful shift from the earlier arcs.

Before this, we were mostly using Solana from the outside. We were creating wallets, sending transactions, minting tokens, configuring extensions, and inspecting what existing programs did.

In Arc 9, we started writing the program logic ourselves.

The next limitation is addressability.

In this arc, the counter account used a fresh keypair address. That works for a first program, but it means the client has to remember where each user's counter lives.

Most real Solana programs need a more predictable way to find program-owned state.

That is where Program Derived Addresses come in.

So Arc 9 gives us the foundation: write a program, store state, enforce a rule, and test it properly.

The next arc builds on that by making the account address itself part of the program design.

Revisit the Arc 9 challenges

Learn Solana the Fast Way

Matthew Revell — Mon, 22 Jun 2026 11:32:02 +0000

As a web or mobile developer, Web3 can seem harder to get to grips with than it really is.

Part of the problem is the vocabulary. Wallets, accounts, mints, programs, signers, authorities, transactions. It can sound as though everything you already know has been replaced by a completely different model.

But many Solana concepts have useful parallels with traditional development.

A transaction is not exactly an API request. A program is not exactly a backend service. A token mint is not exactly a database table. But those comparisons are close enough to give you a way in.

Once you have those bridges, Solana starts to feel less like a wall of jargon and more like another development environment with its own rules, constraints, and patterns.

That is the fast way to learn it: build small things, connect each new idea to something familiar, and let the mental model grow from there.

In this post, we’ll use familiar Web2 ideas as bridges into the Solana model:

Identity and authentication → wallets, keypairs, and signatures
API calls and commands → transactions and instructions
Database records and stored state → accounts
Asset definitions and balances → tokens, mints, and token accounts
Media files and metadata records → NFT metadata
Middleware and business rules → Token-2022 extensions
Backend logic and tests → programs and Anchor

For each one, we’ll explain the Web2 idea first, map it to the Solana concept, then point you to a small challenge where you can try it yourself.

You can read this as a quick map of Solana, but it works better if you pick one section and do the linked challenge.

Each challenge is part of 100 Days of Solana. Sign up, complete the task, and submit your work so your progress counts.

The goal is not to recreate the whole curriculum in one post.

The goal is to give you enough practical understanding that Solana starts to make sense.

1. Identity and authentication: wallets, keypairs, and signatures

In a traditional web or mobile app, identity usually starts with a user account.

Someone signs up with an email address, a password, a social login, or a passkey. Your application stores a user record, manages sessions, and decides what that user is allowed to do.

Solana starts from a different place.

Your wallet is not a user account in the usual Web2 sense. It is a cryptographic identity. More specifically, it is controlled by a keypair: a public key that acts like an address, and a private key that proves you are allowed to sign actions for that address.

The closest Web2 parallel is probably SSH keys or API keys.

If you have used SSH keys with GitHub, the idea is familiar: your public key identifies you, and your private key lets you prove that you are really the person allowed to act as that identity.

On Solana, that proof happens through signatures.

When you send a transaction, your wallet signs it. That signature tells the network: “The holder of this private key authorized this action.”

That is why wallets matter so much. They are not just where tokens live. They are how users approve actions.

Try it

Create your devnet wallet

You’ll create a wallet, request devnet SOL, and check your balance.

The point is not to understand every detail of wallet security yet. The point is to make the first idea concrete:

A Solana wallet is an identity that can sign actions.

When you’re done, submit your result through 100 Days of Solana.

2. API calls and commands: transactions and instructions

In Web2, when your frontend wants something to happen, it usually sends an API request.

That request might create a user, submit a payment, update a profile, or trigger some backend logic.

Solana transactions are not the same as API requests, but the comparison is useful.

A transaction is a signed message sent to the network. Inside that transaction are one or more instructions. Each instruction tells a Solana program what work to perform.

So the rough mapping is:

the transaction is the package being submitted
the instruction is the command inside it
the program is the code that runs
the accounts are the state the program reads or writes
the signer is the identity authorizing the action

This is why Solana transactions can feel strange at first. They are not just “send money from A to B”. They can contain several instructions that run together.

For example, a transaction might create an account and then initialize it. Or it might approve an action and then perform a transfer. If one required part fails, the whole transaction fails.

That gives Solana transactions an important property: they can represent a complete unit of work.

Try it

Send and inspect a devnet transaction

You’ll send a real transaction on devnet, inspect what happened, and connect the abstract idea of “instructions” to something you can actually see.

The key idea is:

A transaction is not just movement of data. It is a signed bundle of instructions.

Submit your completed challenge so your progress is visible.

3. Database records and stored state: accounts

In Web2, you are used to applications storing state in databases.

A user has a row. An order has a row. A payment has a row. Your backend reads and writes that data when something happens.

Solana also stores state, but the model is different.

State lives in accounts.

That word can be confusing because “account” sounds like “user account”. On Solana, an account is more general than that. It is a place where data can live.

An account might hold SOL. It might hold token data. It might store configuration for a program. It might represent part of your application’s state.

A useful Web2 comparison is a database record, but with an important difference: Solana programs do not secretly reach into their own private database. The accounts a program needs are passed into the transaction.

That means the transaction says not only what you want to do, but also which pieces of state the program is allowed to read or write.

This is one of the biggest shifts in the Solana mental model.

You are not calling a backend endpoint that then queries whatever it wants from a database. You are sending an instruction to a program and explicitly providing the accounts involved.

Try it

Inspect a Solana account

You’ll look at a real account and identify its address, owner, and data.

The point is to stop thinking of “account” as only meaning “user account” and start thinking of it as:

A place where on-chain state lives.

4. Asset definitions and balances: tokens, mints, and token accounts

In Web2, if you were building a system with credits, points, tickets, or balances, you might start with a few database tables.

One table might define the asset:

name
symbol
decimal precision
total supply rules

Another table might track balances:

user ID
asset ID
amount

Solana tokens use a similar separation, but the terms are different.

A mint defines the token.

A token account holds a balance of that token for a particular owner.

That distinction matters.

The mint is not your personal balance. It is the source of truth for the token itself: its identity, decimals, supply, and authorities.

A token account is where an owner’s balance of that specific token lives.

So if Alice and Bob both hold the same token, they do not share one balance field on the mint. They each have token accounts connected to that mint.

This is one of the fastest ways to make Solana feel less abstract. Once you create a mint, mint supply, create token accounts, and transfer tokens, you have used several of Solana’s core ideas together.

Try it

This idea takes two short challenges to see end to end.

First, create your first token. You’ll create a mint, create a token account, and mint supply into it.

Then put it to work. You’ll create a token with built-in transfer rules, send it between wallets, and watch the mint and token accounts update.

As you do it, keep this model in mind:

The mint defines the asset. Token accounts hold balances.

When you submit this one, you have more than a screenshot. You have proof that you understand one of Solana’s core building blocks.

5. Media files and metadata records: NFT metadata

In Web2, you rarely store everything directly in one database field.

If you are building a product catalogue, a media app, or a user profile system, you often split things up:

the database stores IDs, names, references, and structured fields
media files live in object storage or a CDN
the frontend combines those pieces into something users can see

NFTs use a similar split.

The token itself gives you the scarce asset: usually a mint with supply of one and zero decimals. But that alone does not tell a wallet what to display.

For that, you need metadata.

Metadata gives clients human-readable information such as:

name
symbol
description
image
attributes
collection information

Some of that information may live on-chain. Some may point to off-chain JSON or media files. The exact mechanics vary depending on the token standard and tooling, but the broad idea is familiar:

The on-chain asset provides ownership and identity. Metadata helps apps understand what the asset represents.

That is why NFTs are worth learning even if you are not especially interested in NFT markets. They teach you how Solana combines ownership, metadata, clients, and off-chain content.

Try it

Add metadata to an asset

You’ll connect an on-chain asset to human-readable metadata and see how wallets know what to display.

Look for the split between:

what lives on-chain
what points off-chain
what the wallet or client chooses to show

The goal is to understand this:

A token becomes meaningful to users when apps can connect it to metadata.

6. Middleware and business rules: Token-2022 extensions

In Web2, business rules usually live in your application.

If you want to charge a fee on every payment, you write that logic in your backend. If you want to prevent a user from transferring something, you add a rule to your application. If you want a balance to grow over time, you might run a scheduled job or calculate the value when the user views it.

That model works, but it depends on your application being the place where the rule is enforced.

Token-2022 changes that.

With Token-2022, some behaviors can be configured directly on the token mint itself. The rule is not just wrapped around the asset by your app. It becomes part of how the asset works.

For example, a token can be configured to:

charge a fee when it transfers
accrue interest in the displayed UI amount
refuse to transfer at all
require additional checks before movement

The Web2 bridge is middleware, but with an important twist.

In a web app, middleware sits in the request path. It runs because traffic passes through your server.

With Token-2022, the middleware-like behavior is inside the asset. The token program enforces it whenever the token is used.

A wallet cannot simply forget to apply the fee. A marketplace cannot route around the rule by calling a different endpoint. The behavior is configured on-chain and enforced by the token program.

Try it

Create a fee-bearing token

You’ll configure a Token-2022 mint with a transfer fee, send the token, and see that the rule is enforced by the token program rather than by application code.

As you work through it, answer three questions:

where is the fee configured?
what happens when the token is transferred?
who enforces the rule?

The key idea is:

Token-2022 lets you put certain business rules into the asset itself, not just into the app around it.

Submit this one if you want a good “aha” moment from the challenge. It is one of the clearest examples of Solana doing something differently from a traditional app stack.

7. Backend logic and tests: programs and Anchor

In Web2, your backend is where application logic usually lives.

It validates input, checks permissions, updates state, triggers side effects, and returns results. You might write tests to prove that the logic works and that failure cases are handled correctly.

On Solana, that logic lives in programs.

A program is deployed code that runs on-chain. Users and clients interact with it by sending transactions containing instructions.

Anchor is a framework that makes it easier to write Solana programs in Rust.

The rough Web2 bridge is backend logic deployed to a shared runtime. That comparison is not perfect, because Solana programs work with explicitly provided accounts rather than a private database connection. But it is close enough to help you begin.

With Anchor, you define:

the instructions your program supports
the accounts each instruction expects
the rules those accounts must satisfy
the handler logic that runs
tests that prove the behavior works

A simple counter program is a good starting point. It teaches the basic flow without too much business logic:

initialize a counter account
increment the counter
test that the value changed
test that invalid actions fail

That is where the Solana model starts to come together. Wallets sign transactions. Transactions contain instructions. Instructions call programs. Programs read and write accounts.

Try it

This one builds up over two short challenges.

First, build and test an Anchor counter program. You’ll scaffold the program, initialize a counter, increment it, and write tests that prove your on-chain logic behaves the way you expect.

Then make the tests earn their keep. You’ll add failure tests, then deliberately break the program and confirm the test suite catches it.

The goal is to understand this:

A Solana program is where your application logic runs, and Anchor gives you a practical structure for writing and testing it.

This is a strong challenge to submit because it shows real progress: you are no longer only using Solana from the outside. You are starting to write logic that runs on-chain.

Keep going with 100 Days of Solana

You do not need to understand all of Solana before you start building.

In fact, trying to learn everything upfront is usually the slowest path.

The faster route is to build small things that make each concept real:

create a wallet
send a transaction
inspect an account
mint a token
add metadata
try a Token-2022 extension
run an Anchor program

Each one gives you a piece of the model.

The challenges above are taken from 100 Days of Solana, a practical challenge series for developers who want to learn Solana by building.

Sounds good? Great, get started and learn Solana today >

Arc 8 Catch-Up: Middleware Inside the Token

Matthew Revell — Mon, 15 Jun 2026 15:16:14 +0000

Arc 8 of 100 Days of Solana was about Token-2022.

That might sound odd at first, because Token-2022 had already shown up in the previous arcs.

Arc 6 used token extensions to explore fees, interest, frozen accounts, and revocable credentials. Arc 7 used Token Extensions to build NFTs from the same token primitives.

Arc 8 made the model explicit.

The whole arc hangs off one idea:

Token extensions are like middleware that lives inside the asset.

For Web2 developers, that is the shift worth noticing.

In a normal app, rules usually sit around the asset. You write backend code. You add middleware. You call a payment processor. You run a cron job. You trust every integration to go through the right path.

With Token-2022, some of those rules can live on the mint itself.

That changes the shape of the system.

A token is no longer just a balance that moves between accounts. It can be a balance with transfer fees, interest display, transfer restrictions, or other behavior attached.

The middleware is not next to the token.

It is part of the token.

Token rules should not depend on every app remembering them

Most Web2 developers have built systems where rules sit outside the thing being moved.

A marketplace might charge a platform fee.

A fintech app might show yield.

A loyalty system might prevent points from being transferred.

A membership product might issue a badge that cannot be sold.

Usually, the rule lives somewhere in your application.

You might write:

calculateFee()
applyInterest()
rejectTransfer()
checkMembershipStatus()

That works as long as every relevant path uses the same logic.

But that is the weak point.

One backend service might apply the fee. Another script might forget it. An integration partner might call the wrong endpoint. An admin tool might bypass the normal flow. A scheduled job might fail. A frontend might display one thing while the ledger stores another.

Token-2022 takes a different approach.

When the extension is configured on the mint, the Token-2022 program enforces the behavior consistently. Every wallet, CLI, dApp, and program that interacts with the token has to deal with the same rule.

That is why the middleware analogy is useful, but only if you take it one step further.

This is not middleware sitting in your app stack.

It is middleware baked into the asset.

Transfer fees are enforced by the mint

Arc 8 started with a fee-bearing token.

The exercise was simple: create a mint under the Token-2022 program, add a transfer fee configuration, mint some supply, and inspect the result.

The important part was not the percentage.

It was where the rule lived.

The transfer fee was not a line of backend code. It was not a webhook. It was not a checkout rule. It was not a convention that wallets were expected to follow voluntarily.

The fee configuration lived on the mint.

That means the token itself carried the rule:

When this token moves, apply this fee.

For Web2 developers, the contrast is familiar.

If you charge a fee through Stripe, you usually build fee logic around the payment flow. You decide how much to collect, when to collect it, how to reconcile it, and which integrations are allowed to move value.

With Token-2022, the fee rule is part of the asset’s behavior. The transfer goes through the token program, and the token program applies the rule.

That is a meaningful difference.

You are not trusting every app to remember the fee. You are configuring a token that cannot move without the fee logic being considered.

That is the first big Arc 8 lesson:

The rule travels with the token.

The fee lifecycle is transfer, withhold, withdraw

Creating a fee-bearing mint is only the first part.

Arc 8 then put the token in motion and followed the fee lifecycle end to end:

transfer → withhold → withdraw

That lifecycle matters because transfer fees do not behave like a normal payment processor settlement flow.

When a fee-bearing token is transferred, the recipient does not simply receive the full amount and then send a fee somewhere else.

Instead, the fee is withheld in the recipient’s token account.

For example, with a 1% transfer fee, a transfer of 1,000 tokens gives the recipient 990 spendable tokens. The remaining 10 are recorded as withheld tokens on the recipient’s token account.

Those withheld tokens are not spendable by the recipient. They sit there until the withdraw authority collects them.

That is a very different mental model from a Web2 marketplace fee.

In a normal app, you might have a payment ledger, a treasury balance, a settlement job, a reconciliation process, and a dashboard showing fees owed.

Here, the withheld amount is visible in the token account itself. The fee authority can later withdraw it using the Token-2022 program.

The important thing is what you did not build.

No custom program.

No payment processor flow.

No webhook.

No cron job.

No separate fee table.

The protocol enforced the fee and stored the withheld amount.

That is the kind of concrete behavior that makes Token-2022 easier to understand. It is not an abstract extension system. It is a rule you can observe on devnet.

Composability means extensions share the same mint

Arc 8 then combined transfer fees with interest-bearing behavior.

This is where the middleware analogy becomes more powerful.

A token can have more than one rule.

The mint can say:

Charge a fee when tokens move.
Display balances with interest over time.

Those behaviors are different, but they can coexist on the same mint.

That matters because Web2 developers often expect separate systems for separate behaviors.

A fee might belong to a payments service.

Interest might belong to a financial calculation service.

Metadata might belong to an asset database.

Restrictions might belong to an access control system.

Token-2022 lets those behaviors be configured as extensions on one mint.

The technical reason is that extensions are stored as structured data on the account. The mint has enough space allocated for the extensions, and the Token-2022 program knows how to read and enforce them.

But the product lesson is simpler:

A token can be configured with multiple behaviors at once.

The fee and interest example also made an important distinction clear.

The transfer fee works on the raw token amount. It moves real token units and withholds part of the transfer.

Interest-bearing behavior affects the displayed amount. It does not continuously mint new tokens in the background. The raw balance does not change every second. The UI amount is computed from the stored amount, rate, and elapsed time.

That is why the two features can coexist cleanly.

The fee changes what happens during transfer.

The interest extension changes how the balance is interpreted when read.

Those are different layers of behavior on the same asset.

Interest is a view, not a background job

The interest-bearing extension is one of the easiest places for Web2 instincts to mislead you.

In a conventional app, if a balance grows, you usually assume something wrote a new value somewhere.

A scheduled job updated the balance.

A database row changed.

A ledger entry was added.

A batch process applied interest overnight.

Token-2022 does not need to work that way.

With the interest-bearing extension, the raw token amount stays the same unless an actual token instruction changes it. What changes is the displayed amount.

The program can calculate the UI amount based on the interest rate and time elapsed.

That is why Arc 8 deliberately used a high rate on devnet. At realistic rates, the change over a short challenge window would be too small to notice. A dramatic rate makes the model visible.

The lesson is not “high yield tokens are good.”

The lesson is:

Display can be computed from state without constantly rewriting state.

For Web2 developers, that is a useful mental shift.

The token account stores raw units. The extension changes how those units are displayed. If you assume “displayed balance increased” means “new tokens were minted,” you will misunderstand what the program is doing.

Arc 8 forced that distinction into the open.

Reading mint configuration is part of building

One of the most useful Arc 8 exercises was not creating another mint.

It was auditing the mints already created.

That matters because Token-2022 configuration is public state. You can inspect a mint and see which extensions it uses. You can read the fee configuration. You can see whether interest-bearing behavior exists. You can check whether a token is non-transferable.

That is the Solana version of inspecting a production schema.

In Web2, the rules of a system are often scattered across:

application code
database migrations
environment variables
payment processor settings
admin dashboards
scheduled jobs
private documentation

On Solana, much of the token’s behavior is visible in the mint account.

That does not mean the whole application is transparent. But it does mean the token’s configuration can be read by anyone.

That is part of the Token-2022 pitch.

The behavior is public.

The configuration is verifiable.

The rules cannot be silently swapped inside a private backend.

That is also why auditing matters.

You should not just create a mint and trust that you typed the command correctly. You should read it back. Check the extensions. Check the authorities. Check the raw configuration. Explain what each extension does in plain English.

That last part is important.

If you cannot describe the behavior without looking it up, you probably do not understand the asset yet.

Non-transferable tokens are useful because they fail

Arc 8 ended the build sequence with a token that refuses to move.

That might sound strange because tokens usually imply transferability. Money moves. Points move. Assets move.

But not every token-like thing should be transferable.

A course certificate should not be sellable.

A membership badge might need to stay with the person who earned it.

A compliance credential might need to remain attached to one wallet.

A proof-of-attendance token might lose meaning if it can be traded.

The non-transferable extension lets the mint encode that rule.

The challenge deliberately tried to break it. Create the token. Mint it. Create a recipient account. Attempt a transfer.

The transfer fails.

That failure is the feature.

In a Web2 app, you might prevent transferability through an API check:

if token.non_transferable:
    reject transfer

But that depends on every path using the same API.

With Token-2022, the token program itself rejects the transfer. The rule is part of the mint’s behavior, and any client interacting with the program has to respect it.

That makes non-transferable tokens different from fees and interest.

Fees and interest are still money-like features. They affect value movement and balance display.

Non-transferability changes the category of the asset. The token starts to look less like currency and more like identity, membership, status, or proof.

Same mint model. Same token accounts. Same CLI.

Different product meaning.

That is why the failed transfer matters so much. It proves the extension is not just descriptive metadata. It changes what the token can do.

Token-2022 is configuration, but not casual configuration

A tempting takeaway from Arc 8 would be:

Token-2022 lets you add features with flags.

That is true, but incomplete.

The better takeaway is:

Token-2022 lets you design token behavior through mint configuration.

That distinction matters.

Extensions feel easy because they can be created from the CLI. But they are not throwaway settings. They shape what the asset is, who can use it, and how every integration will experience it.

A fee-bearing token is different from a normal token.

An interest-bearing token is different from a normal token.

A non-transferable token is very different from a normal token.

Once those behaviors are on the mint, they are part of the asset’s design.

That brings Arc 8 back to the product questions underneath the technical work:

Should every transfer charge a fee?
Who can withdraw withheld fees?
Should balances display with interest?
Should this asset be transferable at all?
Which authorities control the rules?
Will wallets and integrations understand these extensions?

Those are not just CLI questions.

They are product, governance, and integration questions.

Token-2022 gives you reusable building blocks, but you still have to choose the right ones.

Writing turns extensions into patterns

Arc 8 ended by turning the week into a public post and social thread.

That fits the arc well because Token-2022 is easy to explain badly.

You can list extensions all day:

transfer fees
interest-bearing
non-transferable
default account state
permanent delegate
confidential transfers
memo transfer

But a list is not a mental model.

A useful post needs to show the pattern.

For Arc 8, the pattern was a trilogy:

A token that charges a fee.
A token that charges a fee and displays interest.
A token that refuses to move.

That is much more memorable than “I tried some Token-2022 extensions.”

It shows the range of what extensions can do.

One changes transfer economics.

One composes transfer economics with display behavior.

One changes whether transfer is allowed at all.

That is the story.

The best write-up would include what actually happened on devnet: the fee being withheld, the interest-adjusted UI amount changing without a transaction, and the failed transfer error from the non-transferable token.

Those details matter because they prove the learning.

Not:

“I learned Token-2022.”

More like:

“I created a token that charged a transfer fee, watched the fee sit as a withheld amount on the recipient account, stacked interest on the same mint, then built a token that refused to transfer at all.”

That is useful developer storytelling.

What Arc 8 sets up

Strip Arc 8 back to its core and the main ideas are clear:

Token-2022 lets token behavior live on the mint. Transfer fees are enforced by the token program. Fees follow a visible lifecycle: transfer, withhold, withdraw. Interest-bearing behavior changes displayed amounts without constantly rewriting raw balances. Extensions can compose on the same mint. Mint configuration is public and inspectable. Non-transferable tokens show that extensions are not only about money; they can turn tokens into identity, credential, or membership objects.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

Arc 7 showed that NFTs are built from the same token primitives.

Arc 8 pulled the model together: Token-2022 is the extension system that makes many of those behaviors possible without custom on-chain programs.

From here, the question becomes more practical:

How do you choose the right token behavior for the product you are building?

That is the mindset to carry forward.

Use this post as the map, revisit the Arc 8 challenges when you want the hands-on version, and remember the central lesson: with Token-2022, the rule does not sit beside the asset. The rule can live inside the asset.

Arc 7 Catch-Up: Building NFTs from First Principles

Matthew Revell — Mon, 15 Jun 2026 14:28:59 +0000

Arc 7 of 100 Days of Solana was about building NFTs from first principles.

Instead of starting with marketplaces, profile pictures, or NFT culture, the arc stripped the model back to the underlying token mechanics: supply, decimals, mint authority, metadata, collections, and provenance.

After Arc 6, we already knew that Token-2022 can turn tokens into programmable objects with rules: interest, fees, frozen accounts, credentials, revocation, and metadata.

Arc 7 took that model into NFTs.

But the useful surprise was that NFTs are not a completely separate world.

The whole arc hangs off one idea:

A Solana NFT is built from the same token primitives you already know.

For Web2 developers, that is the shift worth noticing.

An NFT is not magic. It is not “a JPEG on the blockchain.” It is not a special category of database record maintained by some mysterious NFT system.

At its simplest, an NFT is a token mint with:

supply locked at one
zero decimals
mint authority disabled
metadata attached
optional collection membership

That is the foundation Arc 7 built up, one layer at a time.

NFTs are not separate from tokens

Arc 7 started by stripping the NFT model down to its smallest useful form.

Before metadata, images, attributes, marketplaces, or collections, an NFT is just a token that cannot be split and cannot be duplicated.

That means two choices matter immediately:

decimals = 0
supply = 1

Zero decimals means the token cannot be divided into fractions. You cannot own 0.5 of it.

Supply of one means there is only one unit.

But supply of one is not enough by itself. If the mint authority still exists, someone could mint another unit later.

So the final step is to disable the mint authority.

That is the moment the token becomes meaningfully non-fungible. The network can see that the supply is one, the decimals are zero, and no authority remains that can create a second copy.

For Web2 developers, a useful comparison is a unique database row with a primary key.

But the analogy only goes so far.

In a normal database, the application owner can usually edit the row, clone it, delete it, or change the surrounding rules. On Solana, once the mint authority is disabled, the supply constraint is enforced by the token program.

The uniqueness is not a UI convention. It is not a marketplace promise. It is part of the token state.

Metadata turns a token into something recognizable

The first NFT in Arc 7 was intentionally plain.

It had no name, no image, no creator story, no attributes, and no collection. It was non-fungible, but not especially meaningful to a human.

That is where metadata comes in.

Arc 7 used Token-2022 metadata to give the NFT a name, symbol, and URI. The URI pointed to an off-chain JSON file containing richer information such as the description, image, and attributes.

That gives us a two-layer model:

On-chain:
mint, supply, decimals, authority, name, symbol, URI

Off-chain:
image, description, attributes, richer display data

That split matters.

The expensive, consensus-critical parts live on-chain. The heavier display information usually lives off-chain. Wallets and explorers follow the pointer: read the mint, get the URI, fetch the JSON, render the asset.

For Web2 developers, this is familiar once you stop treating the NFT as mysterious.

The on-chain metadata is like the core record. The URI is like a foreign key or external reference. The JSON is like the richer document the UI uses to render the page.

The important difference is that the ownership, supply, and core metadata live on a shared network rather than inside one application database.

Arc 7 also made an important historical point. In older Solana NFT workflows, metadata often lived in a separate Metaplex Token Metadata account next to the mint. In this arc, Token Extensions put metadata directly on the mint account itself.

That is why the exercise was useful. It showed the foundation before introducing convenience tooling.

An NFT collection is an on-chain relationship

Once the arc had created a single NFT, the next step was collections.

In Web2 terms, this is easy to understand.

A product belongs to a catalog.
A ticket belongs to an event.
A badge belongs to an award program.
A collectible belongs to a set.

In a database, you might model that with a foreign key:

nft.collection_id = collection.id

Arc 7 built the Solana equivalent using Token-2022 group and member extensions.

Strictly speaking, there are four related pieces:

GroupPointer, which points a collection mint at the account that stores group data
TokenGroup, which stores the group data itself
GroupMemberPointer, which points an NFT mint at the account that stores member data
TokenGroupMember, which stores the member’s group address and member number

In the arc, those pointers point back to the mint accounts themselves, so the group and member data live directly on the relevant mints.

That is why it is fair to talk about a collection mint and member mints, but the underlying model is a little more precise than “one group extension and one member extension.”

The collection mint represents the group. Each member NFT stores membership data that links it to that group.

The important part is that this relationship is not just a label in a marketplace database. It is data stored on-chain and readable by wallets, explorers, and programs.

The arc’s useful mental model was simple:

collection mint = the group
member mint = the individual NFT
member data = the link back to the group

That is the NFT version of a foreign key relationship.

But there is an extra trust step. A pointer by itself is not proof. A malicious mint can point at something it should not. So a client should not stop at “this member says it belongs to this collection.”

It needs to resolve the pointer and verify that the relationship is internally consistent.

That means checking that the member identifies the collection, and that the account being pointed to actually identifies the mint back.

And the creation step matters too. Initializing a group member is not just something any random token creator can do unilaterally. The collection’s authority has to authorize membership.

That is the stronger provenance claim: the collection relationship is not just stored on-chain; it is created through an authorized on-chain action.

As with Arc 6, the schema decisions matter. A mint must be created with the right extensions. You cannot casually retrofit yesterday’s NFT into a collection if it was not created with the member structure it needs.

That constraint can feel annoying, but it is also part of what makes the structure verifiable.

Provenance is something you can inspect

One of the most valuable Arc 7 exercises was not creating another asset.

It was auditing the collection.

That matters because NFT language often gets vague. Provenance, authenticity, ownership, rarity, official collections — these terms can become marketing fog very quickly.

Arc 7 made the idea concrete.

You inspect the collection mint.
You inspect the member NFT.
You check the member data.
You verify that the collection relationship resolves correctly.

That last step matters.

A one-way check is not enough. It is not sufficient to say:

This NFT points to collection C.

A safer check is closer to:

This NFT points to member data.
That member data names this NFT mint.
That member data names collection C.
The group data for collection C names collection C.
The membership was created under the collection’s authority.

That is what makes the relationship more than vibes.

The collection claim is not true merely because a website says so. It is not true merely because a field contains a familiar collection address. It is true when the on-chain relationship resolves correctly and the collection authority has authorized that membership.

For Web2 developers, this is like checking that a foreign key resolves correctly and that the row was created by a service with permission to write to that table.

The difference is that the database is public, shared, and inspectable by anyone.

That is a big part of the NFT value proposition when you remove the hype.

The asset can carry enough information for independent verification, but only if clients verify the relationship properly. Pointers are useful because they let accounts reference each other. They are dangerous if treated as proof on their own.

That is also why the CLI work matters.

It is tempting to think of NFTs through wallets, marketplaces, and images. But the more useful developer habit is to read the underlying state.

What is the supply?
What are the decimals?
Is the mint authority disabled?
Is metadata present?
What URI is stored?
Is there group member data?
Does it name the expected collection?
Does the pointed-to data name this mint back?
Was the membership authorized by the collection authority?

That is how NFTs stop feeling like magic.

Mutability is a design choice

Arc 7 then moved from creation to mutation.

Because the creator still held the metadata update authority, they could rename the NFT, add a custom field, remove that field, or point the URI at a new JSON file.

That is an important lesson because “on-chain” does not always mean “unchangeable.”

Some parts of the NFT were locked. The supply was one. The decimals were zero. The mint authority had been disabled.

But the metadata could still change while the update authority existed.

That is not automatically good or bad. It is a design choice.

A game asset might need metadata updates as it levels up.
A ticket might need status changes.
A credential might need expiry data.
A dynamic collectible might intentionally evolve over time.

But for other assets, mutability might undermine trust.

If someone buys an NFT because of its image, description, or attributes, they care about whether those things can change later. If a collection promises permanence, the update authority becomes part of the trust model.

Arc 7 also showed a practical split between on-chain and off-chain updates.

Changing the on-chain name or URI can happen quickly. Changing the image behind the URI depends on off-chain hosting and caching. Wallets and explorers may continue showing an old image for a while, even after the metadata has changed.

That is a useful reminder: NFTs are not purely on-chain objects.

They are hybrids.

The token, ownership, supply, and metadata pointer can live on-chain. The image and richer media often live somewhere else.

So the storage decision matters. A temporary GitHub Gist is fine for devnet learning. A serious project needs to think harder about durable storage: Arweave is designed for pay-once permanent storage, while IPFS content remains available only while someone continues to pin or serve it.

NFTs are records with ownership, display, and history

The practical Web2 bridge for Arc 7 was not “NFTs are images.”

A better bridge is:

NFTs are unique records with ownership, display metadata, and provenance.

That framing is much more useful.

A normal application might have unique records everywhere:

event tickets
certificates
software licenses
game items
collectible cards
access passes
membership badges
digital art editions
proof-of-attendance records

In Web2, those records usually live inside one company’s database. Ownership and transfer rules are whatever that application says they are.

On Solana, the unique record can be represented as a token mint. Ownership can be held by a wallet. Supply can be locked. Metadata can be attached. Collection membership can be verified.

That does not mean every unique record should be an NFT.

It does mean the NFT model is easier to reason about once you stop starting with the JPEG.

Start with the record.

Then ask:

Should this record be unique?
Should ownership be visible?
Should it be transferable?
Should it belong to a collection?
Should its metadata be mutable?
Should the media be permanent?
Who should hold the update authority?

Those are product questions, not just blockchain questions.

That is the thread connecting Arc 7 back to Arc 6.

Token design is product design. NFT design is product design too.

Writing forces the model to become simple

Arc 7 ended, like the earlier arcs, by writing and sharing.

That matters because NFTs are surrounded by baggage. People bring assumptions from marketplaces, profile pictures, speculation, scams, and culture wars.

A useful developer write-up has to cut through that.

The best post from this arc would not start with “NFTs are back” or “NFTs are dead.” It would explain what was actually built:

I created a token with supply 1 and zero decimals.
I disabled the mint authority.
I added metadata.
I pointed the metadata at a JSON file.
I created a collection mint.
I linked member NFTs to the collection.
I inspected the on-chain relationship.

That is enough.

The point is not to defend NFTs as a category. The point is to understand the technical model.

A good write-up might focus on one concrete surprise:

an NFT is just a token mint with specific constraints
metadata can live directly on the mint with Token Extensions
collection membership can be verified on-chain
provenance is an authorized relationship, not just a marketplace claim
metadata can be mutable if the update authority remains active
off-chain media is only as durable as the place it is hosted

That kind of explanation is useful because it gives the next Web2 developer a handle on the system.

Not hype.

A model.

What Arc 7 sets up

Strip Arc 7 back to its core and the main ideas are clear:

A Solana NFT is built from token primitives. Non-fungibility comes from zero decimals, supply of one, and disabled mint authority. Metadata makes the asset recognizable. Off-chain JSON gives wallets and explorers richer display information. Collections are on-chain relationships between group and member data. Provenance is stronger than a pointer: the member relationship must be authorized by the collection authority and verified in both directions so pointer spoofing does not masquerade as legitimacy. Metadata mutability depends on who controls the update authority.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

Arc 7 showed that NFTs are not a separate technology stack. They are the same token model, shaped into unique digital assets with metadata and provenance.

From here, the question becomes more practical:

How do these assets interact with real programs, wallets, apps, and users?

That is where the next arc can take the model beyond minting and inspection, and into more realistic application behavior.

Use this post as the map, revisit the Arc 7 challenges when you want the hands-on version, and carry the NFT mental model into what comes next.

Arc 6 Catch-Up: Designing Tokens That Enforce Rules

Matthew Revell — Mon, 15 Jun 2026 13:46:26 +0000

Arc 6 of 100 Days of Solana was about designing tokens that enforce rules.

Arc 5 introduced the basics: mints, token accounts, metadata, transfer fees, and non-transferable tokens. Arc 6 pushed that further by asking a more interesting question:

What if the token could carry more of the product logic itself?

That was the real theme of the week.

Using Token-2022 on devnet, we explored interest-bearing tokens, multi-extension mints, frozen accounts, revocable credentials, and the trade-offs that come with adding more behavior to an asset.

The whole arc hangs off one idea:

Token extensions let you compose asset behavior without writing your own on-chain program.

For Web2 developers, that is the shift worth noticing.

In a normal app, rules like interest, fees, access control, and revocation usually live in backend services, database jobs, middleware, or admin tooling.

With Token-2022, some of those rules can live in the token itself.

Extensions are asset features, not app features

Most Web2 products have some kind of internal value system.

A fintech app might offer yield. A marketplace might charge transaction fees. A learning platform might issue certificates. A SaaS product might gate access based on plan status. A compliance-heavy product might freeze or restrict accounts.

Normally, those rules live in the application.

Your backend calculates interest. Your payments layer applies fees. Your database stores membership status. Your admin dashboard revokes credentials. Your API checks whether a user is allowed to transfer, redeem, or access something.

Token extensions move some of that logic into shared token infrastructure.

That does not mean every app should become a token app. It means that, when a token is the right primitive, the rules do not have to be reinvented from scratch. You can use audited, reusable building blocks that every client and integration has to respect.

That is the big idea behind Token-2022.

The token is no longer just a number in a balance bucket. It can have behavior.

Interest-bearing tokens make display different from storage

Arc 6 started with the interest-bearing extension.

The exercise looked simple: create a token with a 5% interest rate, mint 1,000 tokens, then compare the raw balance with the displayed amount.

The surprising part is that the ledger balance does not keep changing in the background.

There is no cron job waking up every minute to update every account. There is no backend service recalculating balances and writing new rows. The token stores the rate and timing information. Readers calculate the interest-adjusted display amount when they need it.

In Web2 terms, it is like a savings account APY where the displayed balance can grow without the underlying ledger entry being rewritten constantly.

That is a subtle but important distinction.

The raw on-chain amount is still the raw amount. The interest-bearing extension changes how that amount is interpreted.

That is why the arc deliberately made the rate dramatic later. At 5%, the difference is easy to miss. At 150%, you can watch the displayed amount climb much faster and see the model more clearly.

The lesson was not “make wild APY tokens.” The lesson was:

Some token behavior is computed by readers, not stored as repeated balance updates.

That is a useful mental model to carry into more advanced token work.

Extensions can be composed

The next step was combining multiple extensions in one mint.

Arc 6 created a token with three behaviors:

metadata, so the token had a name, symbol, and URI
transfer fees, so transfers automatically withheld a percentage
interest, so displayed balances could grow over time

This is where Token-2022 starts to feel different from the original SPL Token Program.

You are not just creating a token and then building everything else around it. You are deciding which behaviors the token itself should support.

In Web2 terms, this is closer to designing the schema and rules for a financial product before launch. You decide what the product is allowed to do, what fields it needs, which authorities exist, and which operations should be enforced by the platform.

The important catch is that extensions are configured up front.

You cannot casually bolt them on later after the mint already exists. That makes token design feel more like database schema design or API contract design than UI configuration.

You should think before you mint.

The other lesson was that extensions operate independently. Transfer fee logic and interest logic can both exist on the same token, but they are not the same feature. One affects what happens during transfer. The other affects how balances are displayed over time.

Composability is powerful, but it does not remove the need to understand each part.

Access control can live at the token level

Arc 6 also introduced the default frozen account state.

That sounds abstract, but the product pattern is familiar.

Some assets should not be freely usable by default. Stablecoins, security tokens, regulated assets, compliance-gated products, and permissioned marketplaces all need some version of:

This account exists, but it is not allowed to move yet.

In Web2, that rule might live in your backend:

if user.kyc_status !== "approved":
    reject transfer

With a default-frozen Token-2022 mint, new token accounts start frozen. Transfers and mints fail until the right authority thaws the account.

That is a very different trust model.

You are not relying on every frontend, integration, script, or API route to remember the compliance check. The token program enforces the state. If the account is frozen, the transfer does not go through.

That was the core lesson of the frozen-account exercise: the failure is useful. It proves the rule is enforced below the application layer.

The pattern is not “add KYC UI.” The pattern is “make unauthorized movement impossible at the token level.”

Credentials need different rules from currencies

Arc 6 then moved from financial rules to identity and credentials.

The revocable credential token combined two extensions:

non-transferable, so the holder could not sell or transfer the credential
permanent delegate, so the issuer could burn it from the holder’s account if it needed to be revoked

That combination is a good example of why token design is not one-size-fits-all.

A currency wants liquidity. A marketplace asset may want fees. A certificate wants the opposite of transferability. Its value depends on being attached to the right holder.

A bootcamp certificate, professional license, compliance credential, or membership badge is only meaningful if the person who earned it is the person holding it.

So non-transferability makes sense.

But credentials also need revocation. A license can expire. A badge can be issued by mistake. A qualification can be withdrawn. A membership can be canceled.

That is where permanent delegate fits. It gives an authority the ability to burn from a holder’s account without needing that holder to sign the burn transaction.

That may sound harsh until you map it to Web2.

If your company issues a certificate, you probably expect the issuer to be able to revoke it. The difference is that, on Solana, that power is expressed through token behavior rather than a private database update.

This is where Arc 6 became less about “tokens as money” and more about “tokens as stateful credentials.”

Reading configurations matters as much as creating them

One of the most useful parts of the arc was not creating a new token at all.

It was inspecting the tokens we had already made.

Arc 6 asked us to compare the mints from the week and read their configurations back out: interest rate authority, transfer fee settings, metadata, freeze authority, default account state, data size, and rent-exempt cost.

That matters because on-chain configuration is not something you should treat as write-only.

If you are building seriously, you need to be able to answer:

Which extensions does this mint use?
Who controls the authorities?
Can those authorities change?
How large is the account?
How much rent-exempt balance does it need?
What rules will every holder be subject to?

That is the token equivalent of inspecting a production database schema or reviewing cloud infrastructure before launch.

You do not just create it and hope. You read it back. You compare it. You verify what the chain actually stores.

Arc 6 also made one trade-off visible: extensions are not free. More extensions mean more account data, and more account data means higher rent-exempt cost.

That is not necessarily a problem. It is just part of the design.

Token design is product design

The throughline of Arc 6 was judgment.

Interest-bearing tokens, transfer fees, frozen accounts, non-transferable credentials, and permanent delegates are all useful, but not universally useful.

Each one answers a different product question:

Should the displayed balance grow over time?
Should each transfer withhold a fee?
Should new accounts start locked?
Should this asset be transferable?
Should the issuer be able to revoke it?

Those are not just technical choices. They are product choices.

The mistake is to start with the extension and then hunt for a use case. The better move is to start with the product rule and ask whether a Token-2022 extension already enforces it.

That is why Arc 6 was a natural follow-up to Arc 5.

Arc 5 taught the basic token lifecycle. Arc 6 taught that token behavior can be composed.

Not every app needs custom program code immediately. Sometimes the right answer is to use the token program that already exists, configure it correctly, and understand the trade-offs.

Writing and sharing made the combinations clearer

Arc 6 ended by turning the week into a public explanation.

That matters because token extensions are easy to list but harder to understand in combination.

Writing forces the useful question:

Which extension combination solves which real product problem?

Interest alone is one pattern. Fees plus metadata is another. Default frozen accounts are a compliance pattern. Non-transferable plus permanent delegate is a credential pattern.

A good write-up does not need to explain every command. It needs to explain the shape:

Here is the Web2 problem.
Here is the token extension combination.
Here is what happened on devnet.
Here is what surprised me.
Here is where this pattern might fit.

That is how learning becomes useful to someone else.

The sharing prompt continued that idea: lead with the problem, show concrete takeaways, include the link, and use the community as a conversation rather than a broadcast channel.

That is especially important in an arc like this. The value is not just “I created another token.” It is “I matched a real-world rule to a token-level feature and proved it works.”

What Arc 6 sets up

Strip Arc 6 back to its core and the main ideas are clear:

Token-2022 extensions let you add behavior to tokens without writing custom on-chain program code. Interest can affect displayed balances without constantly rewriting ledger balances. Multiple extensions can live on one mint, but they must be planned up front. Frozen accounts support access control. Non-transferable tokens plus permanent delegates support revocable credentials. Reading token configuration back from the chain is part of building responsibly.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior.

From here, the question becomes more practical:

How do these tokens interact with real programs on-chain?

That is where the next arc goes: taking the token model beyond the CLI and into program-driven interactions.

Use this post as the map, revisit the Arc 6 challenges when you want the hands-on version, and carry the extension model into what comes next.

Arc 5 Catch-Up: Solana Token Fundamentals Explained for Web2 Developers

Matthew Revell — Mon, 08 Jun 2026 12:21:27 +0000

Arc 5 of 100 Days of Solana opened Epoch 2 by moving from foundation work into programmable assets.

Epoch 1 gave us the basics: wallets, reads, transactions, accounts, and raw on-chain data. Arc 5 put those ideas to work on one of Solana’s most important primitives: tokens.

The arc theme was Token Fundamentals. The Web2 bridge was incentive systems: reward points, marketplace credits, loyalty balances, badges, fees, and transfer rules.

The whole arc hangs off one idea:

On Solana, a token is not just a balance. It is a set of rules enforced by a shared on-chain program.

That is the big shift for Web2 developers.

In a normal app, token-like systems often live in your database and your backend logic. You design tables, write endpoints, check permissions, prevent double-spends, calculate fees, and decide which transfers are allowed.

On Solana, much of that machinery already exists in audited token programs. Arc 5 was about learning to use those programs before trying to invent your own.

Tokens are incentive systems with stronger guarantees

If you have built Web2 products, you have probably seen token-like systems already.

A marketplace might have seller credits. A learning platform might have completion badges. A game might have in-app currency. A SaaS product might track usage credits. A community might issue reputation points or membership status.

Those systems usually depend on application code.

Your backend decides who has what. Your database stores the balances. Your API enforces the rules. If you want transfer fees, you write the fee logic. If you want a badge that cannot be transferred, you add checks in your application.

That works, but the rules live in your system.

Solana changes the shape of that design. With the SPL Token Program and Token-2022, many token rules can be enforced at the program level. That means clients, scripts, and other programs have to follow the same rules.

That is what made Arc 5 interesting. We were not just creating balances. We were exploring what happens when economic rules become part of the asset itself.

A mint defines the token

The first token in Arc 5 was deliberately simple.

Using the spl-token CLI on devnet, we created a token, created an account to hold it, minted 100 units, and inspected the result.

That sounds straightforward, but it introduces the most important token distinction:

A mint defines the token. A token account holds someone’s balance of that token.

If you are coming from Web2, the mint is a little like the currency definition or product catalog entry. It says what the token is: its supply, decimals, and mint authority.

A token account is more like an individual balance bucket. It says how many of that token a particular owner holds.

That distinction matters because you do not receive tokens directly “into a wallet” in the way newcomers often imagine. For each token type, a wallet needs a token account to hold that specific token.

A wallet is more like a filing cabinet. Each token account is a folder inside it.

That is the first Solana token model to carry forward:

Mint account: what the token is.
Token account: who holds how much of it.

Once that clicks, token balances stop feeling like magic.

Token-2022 makes the token itself more expressive

Arc 5 then moved from the original SPL Token Program to Token-2022, also known as the Token Extensions Program.

That distinction matters.

The original SPL Token Program gives you the classic token basics: create a mint, create token accounts, mint supply, transfer, burn, inspect balances.

Token-2022 keeps that familiar foundation but adds extensions: metadata, transfer fees, non-transferable tokens, and other features that would otherwise require more custom infrastructure.

In Arc 5, the first Token-2022 step was a branded token.

We created a mint with metadata enabled, set decimals, and wrote a name, symbol, and URI directly onto the mint.

That is important because metadata gives a token identity. Without it, a token is mostly an address and some numbers. With it, the token becomes recognizable: name, symbol, and a pointer to more information.

For Web2 developers, this is like moving from “database row with an ID” to “product with a name, SKU, description, and image.”

The technical difference is that the identity lives with the token infrastructure, not just in an off-chain app database.

Associated Token Accounts are the default balance bucket

Arc 5 also introduced Associated Token Accounts, or ATAs.

An ATA is a deterministic token account derived from a wallet address and a mint address. In plain English:

For this wallet and this token, there is a predictable default account that holds the balance.

That is useful because it avoids the chaos of every wallet having arbitrary token accounts everywhere.

In Web2 terms, imagine if every user/product pair had a predictable balance record:

balance = getBalance(userId, tokenId)

You do not have to guess where the balance should live. You can derive it.

That is why ATAs show up constantly in Solana token work. They are the standard place to look when asking:

How much of this token does this wallet hold?

Arc 5 used ATAs early because they are not an advanced detail. They are part of the everyday token model.

Transfer fees move marketplace logic into the token program

The most commercially familiar extension in Arc 5 was transfer fees.

In a Web2 marketplace, a payment or transaction fee usually lives in backend code. Someone transfers value, your system calculates a percentage, applies a cap, updates balances, and records the fee.

With Token-2022 transfer fees, that rule can live in the token itself.

In Arc 5, we created a token with a transfer fee. When tokens moved, a percentage was withheld automatically in the recipient’s token account. The recipient could not spend those withheld tokens. The fee authority could later collect them.

That is the important part:

The fee is enforced by the token program, not by a UI convention or backend middleware.

That changes the trust model. A different client, script, or integration cannot simply “forget” to charge the fee. The rule is part of the token’s transfer behavior.

There was also a very real developer gotcha: decimals.

Transfer fee maximums are specified in base units, not display units. If your token has decimals, the number you type may not mean what you think it means. That kind of detail bites everyone eventually, and Arc 5 surfaced it early.

The broader lesson is simple: token economics are product design, but the implementation is exact. Percentages, caps, decimals, authorities, and units all matter.

Non-transferable tokens are useful because they fail

Arc 5 also explored non-transferable tokens, sometimes described as soulbound tokens.

The exercise was intentionally odd: create a non-transferable token, mint it, then try to transfer it and watch the transfer fail.

That failure was the point.

A normal token is valuable partly because it can move. A non-transferable token is valuable because it cannot.

That makes sense for things like:

verified badges
course-completion certificates
membership credentials
KYC or compliance status
reputation markers

In those cases, transferability would undermine the meaning of the token. A certificate is not useful if someone else can buy it from you. A verified badge loses value if it can be traded.

The key lesson was that the restriction is enforced by the token program.

You are not relying on your frontend to hide a transfer button. You are not relying on an API route to reject the request. The token itself cannot be transferred under the rules of the program.

But it can still be burned.

That distinction matters. Non-transferable does not mean indestructible. It means the holder cannot transfer it to someone else. Burning still lets supply be reduced or credentials be revoked, depending on how the system is designed.

The lifecycle is the skill

Arc 5 was not only about individual token features. It also reinforced a repeatable lifecycle:

create → configure → mint → transfer → collect

That pattern showed up again and again.

Create the mint. Configure its rules. Create the account that will hold the token. Mint supply. Transfer some tokens. Inspect what happened. Collect withheld fees if the extension uses them.

That repetition matters because token work can feel fiddly at first.

There are mints and token accounts. Original SPL Token and Token-2022. Display units and base units. Metadata and authorities. Transfer fees and withheld balances. Non-transferable rules and burn behavior.

The way through that complexity is not to memorize every flag. It is to recognize the lifecycle.

Once you can see where you are in the lifecycle, the commands start to make more sense.

Building in public is part of the work

Arc 5 ended, like the earlier arcs, by writing and sharing.

But this week had more to show.

By the end of the arc, we had created tokens, branded them, minted supply, applied fees, collected withheld tokens, and tested transfer restrictions. That is a proper artifact, not just a learning note.

The writing prompt asked us to explain what clicked: why Token-2022 matters, why protocol-enforced rules are different from app-level checks, and what surprised us about token design.

The sharing prompt pushed us to show one concrete moment: the first mint, metadata on Explorer, fees collected by the program, or a rejected non-transferable transfer.

That is good developer storytelling because it gives people proof.

Not “I learned tokens.”

More like:

I created a Token-2022 mint with metadata.
I transferred it.
The program withheld the fee.
Here is the Explorer screenshot.
Here is what surprised me.

That is much more useful to the next person trying to understand the same thing.

What Arc 5 sets up

Strip Arc 5 back to its core and the main ideas are clear:

A mint defines a token. Token accounts hold balances. Associated Token Accounts give wallets a predictable balance account for each token. Token-2022 adds extensions such as metadata, transfer fees, and non-transferable behavior. Those extensions move rules that often live in Web2 backend code into shared on-chain programs.

That is the real shift.

In Web2, token-like systems often depend on your app enforcing the rules.

On Solana, token programs can enforce many of those rules directly.

That is what makes tokens such a useful first step after the foundation epoch. They take identity, accounts, transactions, and state, then combine them into something you can actually design with: incentives, fees, credentials, rewards, and asset behavior.

Arc 5 opened Epoch 2 by showing that tokens are not just things you hold. They are programmable assets with rules.

Use this post as the map, revisit the Arc 5 challenges when you want the hands-on version, and carry the token model into the next arc.

Arc 4 Catch-Up: Solana’s Account Model Explained for Web2 Developer

Matthew Revell — Mon, 08 Jun 2026 12:06:13 +0000

Arc 4 of 100 Days of Solana was about the Solana account model: what state actually looks like on-chain, who can change it, and how developers read and decode it.

Arc 3 gave us the transaction model. We learned that transactions are how Solana changes state.

Arc 4 asked the next question:

Where does that state live?

On Solana, the answer is accounts.

That sounds simple, but it is one of the biggest mental model shifts in the whole foundation epoch. A Solana account is not just a wallet. It is not just a user profile. It is not just a row in a database.

On Solana, almost everything is an account: wallets, programs, token mints, token accounts, sysvars, and application state.

The whole arc hangs off one idea:

On Solana, accounts are the containers that hold state, code, ownership, and balance.

Once that clicks, the rest of Solana starts to fit together.

Accounts are where state lives

In a Web2 app, state usually lives in places you control.

User data might be in Postgres. Files might be in object storage. sessions might be in Redis. App code runs on your servers or serverless functions. Access control often lives in middleware, business logic, row-level security, or API permissions.

Solana rearranges that picture.

State lives in accounts. Programs are accounts too. Wallets are accounts. Token data is stored in accounts. Even bits of cluster state are exposed through special accounts.

That is what people mean when they say “everything is an account.”

It does not mean every account behaves the same way. A wallet account, a token mint, and an executable program account do different jobs. But they share the same basic structure, and that shared structure is what Arc 4 unpacked.

A Solana account has five core fields:

lamports: how much SOL the account holds
data: the bytes stored in the account
owner: the program allowed to modify the account’s data
executable: whether the account contains runnable program code
rentEpoch: a legacy rent-related field

That is the foundation. Different accounts become meaningful because those fields are set differently.

The owner field is the security model

For Web2 developers, the owner field is one of the most important ideas to get right.

It does not mean “the human who owns this account.”

It means:

Which program is allowed to change this account’s data?

That makes owner much closer to a low-level access-control rule than a user-facing ownership label.

In a Web2 app, you might enforce permissions in your API layer:

Can this user update this row?
Can this service write to this bucket?
Can this job mutate this record?

On Solana, the runtime enforces a stricter version of that idea. Only the owning program can modify an account’s data. If a token account is owned by the Token Program, your random application code cannot just rewrite it. If your program owns a data account, then your program defines how that data can change.

That is why the account model matters so much.

Transactions may carry the instructions, but accounts define the state those instructions act on. The owner field helps decide which program has authority over that state.

That is not middleware. It is part of the runtime.

Programs are accounts too

One of the more useful realizations in Arc 4 was that programs are not magical things floating somewhere outside the account model.

Programs are accounts.

The difference is that program accounts have executable: true. Their data contains compiled program code, and their owner is a loader program rather than the System Program.

That is a strange idea at first, but there is a useful Web2 analogy:

The code and the data are separate.

A web server might run application code, then read and write rows in a database. On Solana, a program account contains executable code, while separate data accounts hold the state that program works with.

That separation becomes crucial later.

When you write Solana programs, you are not usually storing mutable state inside the program itself. You are writing code that receives accounts, checks them, reads their data, and changes the accounts it is allowed to change.

So Arc 4 quietly set up one of the most important Solana development habits:

Think in accounts, not objects.

Your program logic is only half the story. The accounts passed into that program are the other half.

Reading an account is like opening a file

Arc 4 started with inspection.

Using the Solana CLI, we looked at a normal wallet account, the SPL Token Program, and the System Program side by side. That made the shared structure visible.

The Web2 analogy here is not perfect, but it helps:

Reading a Solana account is a bit like opening a file or inspecting a database row.

You can see its balance. You can see whether it has data. You can see who owns it. You can see whether it is executable.

But unlike a normal database row, account data often starts as raw bytes. The network can give you the bytes, but it does not automatically know how you want to interpret them.

That is where account decoding comes in.

Raw bytes are where this gets real

Arc 4 was the most “under the hood” week of Epoch 1, and the account decoding work was the reason.

At first, an account’s data field can look like base64 gibberish. That is not because it is meaningless. It is because you are looking at serialized bytes.

The challenge was to decode those bytes and prove that the same account data could be understood in three ways:

with a typed decoder from @solana-program/token
manually, byte by byte, using DataView
through the RPC’s jsonParsed encoding

That is not just busywork. It is the moment where “on-chain data” stops being abstract.

If you have ever parsed a binary file format, decoded a network packet, or mapped bytes into a struct, this is the same kind of work. The data is there. Your job is to know its layout.

Arc 4 introduced several ideas that will keep coming back:

Borsh serialization: how structured data becomes bytes
little-endian numbers: a common source of decoding bugs
base64: how RPC often returns account data
hex: useful for debugging raw bytes
base58: how Solana addresses are displayed

This was the hardest part of the arc, but it was also the most transferable.

If you can decode account data, you are no longer limited to what a block explorer chooses to show you. You can inspect state yourself.

The System Program is the account clerk

Arc 4 also took us one layer deeper into the system itself.

The System Program is one of the native programs that makes Solana work. A useful way to think about it is as the clerk that creates and labels accounts.

It can create accounts. It can assign ownership. It can allocate space. It handles basic SOL transfers.

That makes it feel a little like part of an operating system. Not your application logic, but the lower-level machinery that makes files, processes, permissions, and memory possible.

Sysvar accounts are another useful piece of that system layer. They expose read-only cluster state, such as clock or rent information, through accounts.

A rough Web2 analogy would be /proc on Linux: system information exposed as readable data.

Again, the analogy is not exact. But it helps place the idea. Solana’s account model is not only for application state. It is also how the system exposes information about itself.

Block explorers are blockchain DevTools

After decoding account data by hand, Arc 4 stepped back and looked at Explorer again.

That was useful because block explorers are not just places to paste transaction signatures. They are the debugging surface for a public blockchain.

Solana Explorer, Solscan, and similar tools are basically UI wrappers around public chain data. They show accounts, transactions, owners, program logs, balances, token data, and instruction details.

If you are used to browser DevTools, database consoles, or log dashboards, this is the role explorers play.

They help you answer questions like:

What account am I looking at?
Who owns it?
Is it executable?
What data does it hold?
Which transaction changed it?
What logs were emitted?

Reading explorers fluently is a real Solana development skill. It lets you move between your code, RPC calls, transaction signatures, and on-chain state without guessing.

Arc 4 made that explicit.

Writing helps the model settle

Arc 4 ended the same way the earlier arcs did: by writing and sharing.

That matters especially for this arc because the account model is not something you fully absorb by reading one definition. It takes a few passes.

You inspect an account. You compare it with another one. You decode bytes. You look at a program. You notice that the same five fields keep showing up. Then you try to explain it to someone else.

That is when the model starts to stick.

Writing about the account model forces useful questions:

What does owner really mean?
How is a program also an account?
Where does state live?
Why is account data raw bytes?
What does rent-exempt storage mean?

Those questions are exactly the point.

The goal is not polished certainty. The goal is a clearer map.

What Arc 4 sets up

Arc 4 closed Epoch 1 by giving us the data model underneath everything else.

Strip it back to the core ideas:

Accounts are where Solana state lives. Every account has the same basic fields. The owner field controls who can change account data. Programs are executable accounts. Application state lives in separate data accounts. Raw account data is bytes, and decoding those bytes is a core developer skill.

That brings the foundation epoch together.

Arc 1 gave us identity: keys, wallets, addresses, and devnet SOL.

Arc 2 gave us reads: RPC calls, balances, transaction history, and public blockchain data.

Arc 3 gave us writes: signed transactions, confirmation, and failure modes.

Arc 4 gave us state: accounts, ownership, executable programs, raw data, and decoding.

From here, the next step is natural.

Once you understand identity, reads, writes, and state, you are ready to build with the programs that own and modify those accounts.

Use this post as the map, revisit the Arc 4 challenges when you want the hands-on version, and carry the account model into what comes next.

Arc 2 Catch-Up: Reading Solana Like a Public Database

Matthew Revell — Mon, 08 Jun 2026 11:59:40 +0000

Arc 2 of 100 Days of Solana was about learning to read from the blockchain.

In Arc 1, we created wallets, worked with addresses, got devnet SOL, and started building the basic identity layer we need to interact with Solana. Arc 2 shifted the focus from identity to information.

What can you read from Solana? How do you ask for it? What comes back? And how is that different from fetching data from a normal Web2 API or querying a database?

The whole arc hangs off one useful mental model:

Solana is a massive public database where every table is readable and every query is free.

That is not a perfect technical description, but it is a useful starting point. If you are coming from Web2, Arc 2 is where Solana starts to feel less like an abstract blockchain and more like a data source you can inspect, query, and build interfaces around.

Reading from Solana feels familiar

Reading from Solana is the easy part to map onto Web2.

You ask for a wallet balance. You fetch recent transactions for an address. You inspect account data. The network answers.

That shape feels familiar if you have ever called a REST API, queried a database, or built a dashboard around backend data.

In Arc 2, the first read was deliberately small: use @solana/kit, connect to devnet, and call getBalance for a wallet address.

That one call teaches more than it first appears to.

There is no user session. No API key. No private dashboard. No auth header. The address is public, the balance is public, and the network can return it directly.

That is the first shift:

On Solana, public data is public by default.

For Web2 developers, that can feel backwards. In most application databases, data starts private. You expose it through APIs, auth rules, dashboards, and permissions. On Solana, a lot of the base data is already out in the open. The job of your application is often not to unlock access, but to make public data understandable and useful.

A wallet balance is just the first query

Once you can fetch a balance, the next step is obvious: fetch activity.

Arc 2 moved from getBalance to recent transaction history. Using getSignaturesForAddress, we queried the most recent transactions for an address and displayed the signature, slot, timestamp, and status.

If getBalance is like:

GET /users/:id/balance

then recent transactions feel more like:

GET /users/:id/transactions

The pattern is familiar. The data is not.

A transaction signature is not just a random ID. It is the identifier you can use to look up what happened. A slot is not quite a timestamp; it is Solana’s way of ordering batches of work over time. A block time gives you a familiar Unix timestamp when one is available.

This is where Solana starts to feel like a database with its own vocabulary.

You can query it. You can display the result. You can build UI around it. But the records you get back are blockchain records, not rows from your own application database.

That distinction matters.

You are not asking your backend, “What did this user do in my app?” You are asking the network, “What activity is visible for this address?”

A dashboard turns reads into something useful

The first two reads happened in scripts. That is a good way to learn the API, but it is not how most users experience software.

So Arc 2 moved the same read patterns into a small browser dashboard.

The dashboard took an address, fetched its balance, pulled recent transactions, and displayed the results in a simple web interface. Same Solana calls. Different surface.

That is a useful moment because it shows how normal this can feel.

You are still doing familiar frontend work: input fields, loading states, error handling, formatted output. The Solana-specific part is the data source.

A read-only dashboard is also a good early blockchain app because the risk is low. You are not signing anything. You are not moving funds. You are not changing state. You are just helping someone understand public data.

That makes Arc 2 a good bridge for Web2 developers. You can use existing frontend instincts while slowly replacing “my backend API” with “the Solana RPC endpoint.”

Accounts are not tables, but the database analogy helps

The conceptual center of Arc 2 was the comparison between Solana accounts and Web2 databases.

The database analogy helps because it gives you a place to start. Solana stores state. You can read that state. Programs interact with that state. Accounts have owners. Data has structure.

But the analogy breaks quickly.

In a normal database, you might expect tables, schemas, indexes, joins, private rows, server-side filtering, and application middleware enforcing access control.

Solana does not work like that.

On Solana, everything is an account: wallets, programs, token accounts, program-owned data. Accounts do not query each other. There are no joins. You usually assemble what you need off-chain by making RPC calls, reading account data, and interpreting the results in your app.

That is a major shift.

In Web2, the database often sits behind your application. Your server decides what to query, what to hide, what to join, and what to return.

On Solana, the data is public, the runtime enforces ownership and write rules, and your application often becomes the layer that makes raw public state usable.

That is why “Solana is a public database” is helpful, but incomplete. It is not Postgres with a blockchain logo. It is a shared state layer with different rules about visibility, ownership, storage, and writes.

Storage has a price tag

Arc 2 also introduced a detail Web2 developers do not usually think about directly: storage cost.

In most Web2 apps, storage cost is real, but abstracted. You pay a cloud bill. Your database grows. Maybe you worry about indexes, backups, or object storage. But individual records do not usually arrive with an obvious upfront storage deposit.

Solana makes storage more explicit.

Accounts need enough lamports to be rent-exempt. That deposit depends on the amount of data the account stores, and it can be returned if the account is closed.

That is a very different mental model from “just insert another row.”

It means storage is not just a backend implementation detail. It is part of the application model. If your app needs on-chain state, someone has to pay for the account space that holds it.

Arc 2 did not require us to build with that model yet, but it planted the idea early: on Solana, reading is free, but storing state is not invisible.

Devnet and mainnet are separate worlds

Arc 2 also made the network environment visible.

In Web2, developers are used to staging and production. Same code, different database. Same API shape, different base URL. Different data, different risk.

Solana has a similar idea with devnet and mainnet.

The RPC calls can look identical. The address can be the same. But the network you query changes everything.

A wallet might have devnet SOL and no mainnet SOL. It might have activity on one network and no history on the other. Devnet is not a sandboxed view of mainnet. It is a separate environment with separate data.

That is a useful Web2 bridge:

Changing networks is like pointing the same app at a different database.

The code shape stays familiar. The data source changes. The consequences change too.

Devnet is where you can experiment freely. Mainnet is where the real assets and real history live.

Writing turns learning into understanding

Arc 2 ended by stepping away from the code and asking us to explain what we had learned.

That was not filler. Writing is part of the learning loop.

When you try to explain Solana accounts, RPC calls, devnet, public data, or transaction history to someone else, you quickly find the gaps in your own understanding. The rough edges become visible. The parts that felt “sort of clear” either sharpen or fall apart.

That is valuable.

A good technical learning journey is not just:

read docs → copy code → move on

It is closer to:

try something → build something → explain it → share it → notice what still feels unclear

Arc 2 followed that pattern. We read on-chain data, turned it into a browser dashboard, compared it against Web2 databases, wrote about what clicked, and shared the work publicly.

That turns a week of exercises into something more durable.

What Arc 2 sets up

Strip Arc 2 back to its core and the main ideas are clear:

Solana data is public by default. You read it through RPC calls. Wallet balances, transaction history, programs, and data all live in accounts. Devnet and mainnet are separate environments. Reading is free, but storing state has a cost.

That gives us the bridge into Arc 3.

Once you understand how to read from Solana, the next question is obvious:

How do you change it?

On Solana, the answer is transactions.

Arc 3 picks up there: signed requests to change on-chain state, SOL transfers, transaction anatomy, confirmation, failure modes, and the write path developers use to interact with the network.

Use this post as the map, revisit the Arc 2 challenges when you want the hands-on version, and jump into Arc 3 with the read model already in place.

$500 Challenge Drop

Matthew Revell — Fri, 22 May 2026 14:54:18 +0000

If you’re taking part in 100 Days of Solana, look out for the $500 Challenge Drop.

Complete Monday’s or Tuesday’s challenge (Day 36 or 37) and you’ll be entered for a random chance to win $500.

That’s it: complete the challenge, submit your work, and you’re in the draw.

What is 100 Days of Solana?

100 Days of Solana is a daily, hands-on learning challenge from MLH and Solana for Web2 developers who want to understand Solana by building with it.

Each challenge introduces one practical concept at a time, using familiar JavaScript tooling while gradually moving from fundamentals like keypairs and transactions into tokens, accounts, and programmable assets.

This week’s challenges continue the move into Token Extensions, where Solana tokens start to feel less like static assets and more like programmable building blocks.

How to enter

To be entered for the $500 Challenge Drop:

Complete Monday’s or Tuesday’s 100 Days of Solana challenge
Submit your work at the bottom of the challenge
You’ll be entered for a random chance to win $500

Start here: mlh.link/solana-100

Complete the challenge, submit your work, and you’re in.

Arc 1 Recap: Keypairs, Wallets, and Solana Fundamentals

Matthew Revell — Fri, 22 May 2026 10:16:13 +0000

Typical web and mobile development often starts with a few familiar questions:

What's the data model going to look like?
How am I going to handle user accounts and auth?
Where am I going to host this thing?

Web3 development has its own set of "how do I start?" questions but they're not the same as what you'd expect if you're coming from a Web2 background.

Arc 1 of 100 Days of Solana was all about learning those fundamentals.

What are the Solana equivalents of user accounts, dev/prod environments, data storage, and so on?

Identity starts with a keypair

Identify works differently in the Web3 world. It starts with a keypair, rather than an account someone creates for you.

But the similarities with typical user accounts break down once you look at the detail.

A Solana keypair is created on your own computer.

There is no signup request, no account creation API, and no backend service issuing you an identity. Your machine generates two linked pieces of data:

a public key
a private key

The public key is your Solana address. You can share it freely, paste it into a faucet, or look it up in a block explorer.

The private key proves that you control that address. You keep it secret, just like you would keep an SSH private key secret.

The important thing to understand is this:

Creating a keypair gives you a valid Solana address, but it does not automatically create anything on-chain.

That can feel strange if you are coming from Web2. In a normal web app, a user account usually appears only after a row is inserted into a database. On Solana, the address can exist before the network has stored any data for it.

So there are two related ideas:

The address:
This exists as soon as your keypair exists. It is just derived from your public key.

The on-chain account:
This exists on a specific Solana cluster only once the network starts storing state for that address. For example, that might happen when you receive devnet SOL from a faucet.

That means a brand-new address can be completely valid, even if Solana Explorer shows no account data for it yet.

It is a bit like generating an SSH key. You can create the key locally before any server knows about it. The public key is real immediately, but it only becomes useful on a specific server once that server has been told about it. On Solana, your address is real immediately, but a particular cluster only stores account state for it once something happens there.

This is one of the first places where the usual Web2 mental model starts to shift. In a Web2 app, an account usually begins as something a service creates and stores. On Solana, control is cryptographic: you control the wallet because you hold the key that can sign for it. No company needs to store your credentials before the address exists, and no admin panel can recover the private key for you.

That is not the whole story of Solana, but it is one of the foundations everything else builds on. If you do not understand what controls an address, transactions, accounts, tokens, and programs all feel more mysterious than they need to.

From generated key to funded address

If you know one thing about Web3, it might be that each blockchain has its own currency. On Solana, that currency is SOL.

SOL is what pays for activity on the network. In Arc 1, though, we did not start by spending real money. We started with devnet SOL: free test tokens used on Solana’s developer network.

A few lines of @solana/kit produced a brand-new keypair. The important call was small: generateKeyPairSigner() created a signer and returned an address that we could print straight to the terminal.

That first step is intentionally plain. Before there is a wallet app, login screen, dashboard, or account setup flow, there is just a keypair:

a public key, which gives you a Solana address
a private key, which proves you control that address

We then funded that address with free devnet SOL from the Solana faucet. More precisely, the faucet sent lamports to the address. Lamports are the smallest unit of SOL, a bit like cents are to dollars, except 1 SOL equals 1,000,000,000 lamports.

After that, a balance check showed that the address now had account state on devnet.

That is a useful break from the usual Web2 sequence.

In a typical web app, the user account usually starts as a row in a database. The app creates the account, stores the user record, and then the user can do things.

On Solana, the address can exist first. It is valid as soon as the keypair is generated. The network only starts storing account state for that address on a particular cluster once something happens there, such as receiving lamports.

Arc 1 also introduced devnet, one of the most important environments for learning Solana. We were not using local mocks or screenshots of a production system. We were using a real Solana cluster with the same core APIs and concepts as mainnet, but with tokens that have no real-world value.

Persistence makes the key useful

Generating a keypair is only the first step.

If the keypair lives only in memory, it disappears when the script exits. That is fine for a quick demo, but it is not enough if we want to keep using the same Solana identity.

So the next step was persistence. We saved the keypair to a local JSON file, then loaded it again each time the script ran.

That gave us the same address across multiple runs.

This is the point where Solana identity starts to feel less abstract. In a Web2 app, your identity is usually tied to something recoverable: an email address, a password reset flow, maybe a login provider.

With a keypair, the private key is the thing that matters.

If someone has the private key, they can sign transactions for that address. They do not need your password. They do not need your email account. They do not need approval from a backend service.

For devnet, storing a keypair in a local JSON file is fine. There is no real value at stake. But the same approach would be a serious mistake for mainnet funds or production users.

Arc 1 made that visible early:

Key storage affects security.
Address reuse affects privacy.
Signing is how authorization works.

Lamports make value precise

Arc 1 also introduced the unit Solana programs actually work with: lamports.

Wallets usually show balances in SOL because that is easier for humans to read. But Solana code works in lamports because programs need exact whole-number values.

One SOL is 1,000,000,000 lamports.

This should feel familiar if you have worked with payments APIs. Stripe does not ask you to send $19.99 as a decimal amount. It asks for 1999 cents, because money should not be handled with floating point arithmetic.

Solana follows the same basic idea. The network needs every validator to calculate the same result exactly. That means balances, transfers, and fees are represented as integers, not rounded decimal values.

So there are two units to keep straight:

SOL is the readable display unit.
Lamports are the exact unit used by the network.

That small distinction teaches a bigger Solana lesson. What humans see is not always what programs store, sign, or verify. As a developer, you need to know when you are dealing with a friendly display value and when you are dealing with the precise value the network will actually use.

The app gets an address, not your private key

After working with raw keypairs in scripts, we connected a real browser wallet.

Using the Wallet Standard and @wallet-standard/app, we built a browser app that could detect installed wallets such as Phantom, Solflare, and Backpack. The app requested a connection, then displayed the selected address and its devnet balance.

That is the important distinction: the app could show the address and read the balance, but it never handled the private key.

The wallet kept custody of the key. The app only received the public address.

For Web2 developers, this is closer to using an external identity provider than asking users to type their password into every app. The app delegates key management to the wallet. When it needs proof that the user controls an address, it asks the wallet to sign something.

But connecting a wallet is not the same as a full login session.

A wallet connection gives the app an address. It tells the app, “This is the address the user has chosen to share.” It does not automatically prove that the user should stay logged in, access a private account, or perform sensitive actions.

For that, an app usually needs a separate signing step. The wallet signs a message or transaction, and that signature proves control of the address. The wallet should ask the user before signing anything meaningful.

That is why real Solana apps should not ask users to paste secret keys into a form. The private key stays in the wallet. The app asks the wallet for addresses and signatures.

Arc 1 covered both raw keypair management and browser wallet connection because they teach different parts of the same model:

Raw keypairs show what is happening underneath.
Wallet connections show how users should normally interact with apps.

If you come from Web2, connecting a wallet can look a bit like “Sign in with Google.”

Your app does not handle the user’s Google password. The user approves access through Google, and your app receives enough information to recognize them.

A Solana wallet plays a similar role in the app experience. It holds the user’s keys, asks for approval, and gives the app a public address to work with.

But the comparison only gets you so far.

Google is an identity provider. It can reset access, suspend accounts, enforce policies, and sit between the user and the apps they use.

A non-custodial wallet is different. It manages keys and asks the user to approve signatures, but it cannot recreate a lost private key. It also cannot invalidate a private key that still exists somewhere else.

That changes the shape of identity.

In a typical Web2 app, identity often starts with a database row. The app creates a user account, stores profile data, and provides recovery flows if something goes wrong.

On Solana, the address is the durable identifier. A signature is the proof that someone controls that address.

Your app can associate data with an address, but it does not own the user’s identity.

That can feel like losing control if you are used to backend-owned accounts. But it is one of the tradeoffs Solana asks developers to understand. Users can bring the same address to different Solana apps. They can connect, approve, disconnect, and move on.

That portability is powerful, but it has a privacy cost. If someone reuses the same address across many apps, their activity may be easier to link together.

That is why the Web2 analogies in Arc 1 are useful, but only up to a point:

SSH keys help explain keypairs.
Payments APIs help explain lamports.
OAuth-style login helps explain wallet connection.

None of those comparisons maps perfectly. But each gives Web2 developers a foothold before the Solana model starts to feel natural.

There is no ordinary password reset

Arc 1 also introduced one of the harder parts of the Solana mental model:

If you lose the private key, there is no ordinary password reset.

In a typical Web2 app, the service controls the account system. That is why it can offer recovery flows. You can reset a password, verify an email address, contact support, or use an identity provider to get back in.

That convenience comes with a tradeoff. The same service can also lock you out, leak credential data, change the rules, or shut the account down.

Solana works differently.

On Solana, control comes from signing. If you can sign with the private key for an address, you control that address. If you cannot sign, the network does not know that you are “really” the owner.

That makes key storage a real product decision, not just a technical detail.

Different approaches make different tradeoffs:

Browser wallets are convenient, but connected to everyday devices.
Hardware wallets add protection, but introduce more friction.
Custodial services can offer recovery, but someone else holds or manages the keys.
Multisig tools can share control across multiple people or devices.
Cold storage can improve security, but is less practical for frequent use.

The rule for real apps is simple:

Do not ask users to paste secret keys or seed phrases into your app.

A Solana app should connect to a wallet and ask for signatures. The wallet keeps the private key. The user approves or rejects the request. The app receives only what it needs.

Recovery also has to be designed deliberately. It is not a default support flow you get for free. Seed phrases, hardware wallets, multisig setups, and custody providers all exist because key loss, key theft, and shared control are real product problems.

Once that clicks, self-custody stops sounding like a slogan. It becomes a set of design choices about security, usability, and recovery.

You are building around a different foundation: control is proven by signatures, not granted by a service.

What Arc 1 sets up

By the end of Arc 1, we had worked through the core Solana fundamentals that everything else builds on:

generating a keypair in code
understanding public keys and private keys
funding an address on devnet
seeing the difference between an address and account state
saving and reloading a keypair from a local file
converting between SOL and lamports
reading raw lamport balances in logs
connecting a browser wallet to a web app
- understanding that connecting a wallet and signing are separate actions
explaining Solana identity in our own words

For Web2 developers, some of this should feel familiar.

If you have generated an SSH key, you already have a starting point for understanding keypairs. If you have used “Sign in with Google,” you already have a rough analogy for wallet connection. If you have handled money in cents through a payments API, you already understand why Solana uses lamports instead of decimal SOL values in code.

None of those comparisons is perfect. But they give us useful footholds.

Want to see the full thing? Check out the 100 Days of Solana daily challenge series.

Epoch 2: From Reading to Creating

Matthew Revell — Mon, 18 May 2026 12:18:24 +0000

Epoch 1 was about learning how Solana works: wallets, accounts, transactions, balances, and on-chain state.

Epoch 2 turns that foundation into something you can build with. You’ll create tokens, add metadata, experiment with fees and transfer rules, mint NFTs, and see how assets can carry behavior of their own.

What "programmable asset" actually means

We first met SOL pretty early in Epoch 1. It is the currency used on Solana to pay fees, fund accounts, and it gave you a clean first lap around transactions and Explorer.

So it would be easy to think of Solana mainly as a network for moving SOL around.

But Solana also lets you create assets whose rules are part of the asset itself: who can create more, who can hold them, whether they can move, whether transfers take a fee, and what metadata other apps can read.

That might sound like a lot, but the next four weeks of 100 Days of Solana break it down step by step.

If you've built Web2 products, you've probably worked with things users can earn, hold, spend, unlock, or display: loyalty points, in-app credits, course badges, gaming currencies, access passes, reputation scores.

In a traditional app, those things live in your database. Your backend decides how they are created, who they belong to, whether they can move between users, and what they can be used for.

On Solana, some of those rules can move into the asset itself.

To make that work, Solana splits those ideas across a few building blocks. A mint describes the asset. Token accounts record who holds it. Authorities decide who can create more, freeze accounts, update metadata, or collect fees.

A basic token can answer the first question: who holds how much?

But product ideas usually need more than that. What is this asset called? Can another app recognize it? Can it be transferred? Should transfers take a fee? Should a new holder be approved before they can use it?

Token-2022 is Solana’s token program for that next layer. It adds optional extensions, which are predefined features for metadata, fees, frozen accounts, non-transferability, interest-bearing display amounts, and other asset behaviors.

Some of those rules are configured on the mint. Some are tracked on token accounts. But the important shift is this: the rules are enforced by the token program, not only by your application.

Arc 5: A token and then a name for it

The first arc of Epoch 2 starts with the simplest asset you can create: a token on devnet.

You create the mint. You issue some supply to your own wallet. You open Explorer and there it is: an asset you created, controlled by your wallet, sitting on a public network anyone can inspect.

At first, though, it is still pretty bare.

A mint address is useful to a program but it does not mean much to a person. It is just a long base58 string. So the next step is metadata: a name, a symbol, and a URI that can point to richer details such as an image and traits.

That is when the token starts to feel less like a raw account and more like something you can work with.

This first arc of Epoch 2 also introduces a more important design choice: should this asset be transferable?

Not every asset should move freely. A certificate of completion, a verified badge, or a reputation score should belong to the person who earned it. In this arc, you will create a non-transferable token and try to send it to another wallet. And you'll see that the token program refuses the transfer because the rule is part of the asset.

Arc 6: Rules the network enforces for you

Arc 6 is where Token-2022 starts to matter.

You will create an interest-bearing token: a mint with an interest rate in its configuration. The raw balance does not change, but compatible wallets and clients can calculate a display amount that grows over time.

In a Web2 app, that kind of behavior might need timestamps, background jobs, database updates, and careful UI logic. With Token-2022, the rate is part of the token configuration, and compatible clients use it to calculate the displayed balance.

Token-2022 calls these optional features extensions. An extension is a built-in capability you add to a token: metadata, transfer fees, interest-bearing display amounts, frozen accounts, non-transferability, and so on.

In Arc 6, you start combining them.

A token might have metadata, a transfer fee, an interest rate, or other built-in rules. Some extensions can work together; others cannot. That means token design starts to feel a little like schema design: you need to decide what the asset should be able to do before you create it, because some choices are permanent and others are hard to change later.

The arc also introduces default frozen accounts. This means new token accounts start frozen and cannot be used until a freeze authority thaws them.

That gives you a simple version of a gated asset flow. Not every holder is automatically eligible. Someone has to approve the account before it can transact.

Finally, you will combine non-transferable tokens with permanent delegates to model a revocable credential. The holder cannot transfer it to someone else, but a designated authority can still burn it.

That gives you something close to: this credential can be issued and revoked, but it cannot be passed on.

You could model that in a database, but the rule would live inside your application. Here, the rule is part of how the asset works.

Arc 7: NFTs use the same building blocks

Arc 7 moves from fungible tokens into NFTs.

The useful surprise is that NFTs are not a completely separate technical world. At their simplest, they use the same basic ingredients you will have already covered up to that point: a mint, token accounts, metadata, and authority.

The difference is uniqueness.

A normal token is designed so many people can hold units of the same asset. An NFT is designed so there is only one of that asset. One token. One current owner. One piece of metadata that explains what it represents.

You will build the simplest version first: a unique asset on devnet that only your wallet owns. Then you will add the things people expect from an NFT: a name, an image URI, traits, and membership in a collection.

That is where metadata matters again. The NFT stops being just a unique on-chain asset and starts becoming something wallets, explorers, and other apps can present in a recognizable way.

The most satisfying moment in this arc comes when you update it.

You change the metadata on your live devnet NFT, then refresh a compatible wallet or explorer. The image changes. The name changes. The transaction has a signature anyone can audit, and the updated state is visible to compatible tools that read the standard.

You are not just editing a file or changing a row in your own database. You are changing asset state on a public network.

Arc 8: Assets that carry their own behavior

Arc 8 brings the whole epoch together.

You will create a fee-bearing token with a 1% transfer fee. Send 100 tokens to another wallet, and the recipient receives 99. The remaining 1 is withheld automatically according to the rules configured on the token.

That is the important part: your application did not calculate the fee, intercept the transfer, or run a background job. The token program enforced the rule.

Then you will run the rest of the lifecycle. You will inspect the withheld fees, harvest them from token accounts up to the mint, and withdraw them using the withdraw authority.

That gives you the full pattern: transfer, withhold, harvest, withdraw.

From there, the arc pulls together the ideas from the previous weeks. You will stack interest behavior on top of transfer fees. You will audit token mints to understand which rules are configured. You will revisit non-transferable tokens now that you have seen how fees, metadata, frozen accounts, and authorities all fit together.

By this point, Token-2022 should feel less like a list of features and more like a design toolkit.

The point is not that every token should use every extension. Most should not. The point is that you now have a vocabulary for asset behavior: fees, identity, display logic, access control, transfer restrictions, and revocation.

You can design those behaviors without writing a custom Solana program from scratch.

What you'll walk away with

By the end of Epoch 2, you’ll have a small portfolio of real Solana experiments on devnet.

Custom tokens with metadata. Transfer fees configured and inspected. Interest-bearing display amounts. Frozen accounts thawed by an authority. Non-transferable assets that refuse to move. A 1-of-1 NFT minted, added to a collection, updated, and verified on-chain. A fee-bearing token whose withheld fees you harvested and withdrew yourself.

You’ll also have written about what you built.

And that's because explaining a concept in your own words is one of the best ways to find out whether you actually understand it.

So, let's get into it!

Join us on the 100 Days of Solana journey.

Solana Writing Challenge: End of Epoch 1

Matthew Revell — Fri, 15 May 2026 09:45:48 +0000

If you’ve been taking part in 100 Days of Solana so far, you’ve probably discovered that Web3 isn’t as mysterious as it first appears.

And now it's your turn to help other web and mobile developers make the same realization.

To celebrate the end of Epoch 1, where we looked at Solana fundamentals, we're running a week-long 100 Days of Solana Writing Challenge. The focus is simple: write a DEV post that helps another developer understand, build, debug, or try something in Solana.

You don’t need to be an expert. You don’t need to write the definitive guide to anything. The best post might be a small explanation, a useful analogy, a bug you fixed, a project you built, or the moment a concept finally clicked.

What matters is that another developer can read it and come away thinking: “Okay, that makes more sense now.”

Prizes

And, of course, we have prizes.

We’ll award $500 prizes in three categories:

Most helpful post: for the post that does the best job of helping another developer understand, build, debug, or try something in Solana.
Most read, on-topic post: for the eligible post with the most reads during the challenge period.
Best posting streak: for the strongest set of four high-quality, helpful posts published during the challenge week.

We also have ten DEV++ subscriptions for notable submissions that stand out for clarity, originality, practical value, or community spirit.

To be eligible:

Your post must be published on DEV between 15 May and 22 May
Your post must include the 100daysofsolana tag
Your post must be relevant to Solana or your 100 Days of Solana learning journey
Your post must be written to help other developers, not just to announce participation
You must be registered for the 100 Days of Solana challenge

Use our template to get started!

Questions?

Have questions about the challenge or whether your post idea fits?

Ask in the 100 Days of Solana Discord channel. We’re happy to help you find an angle, shape an idea, or turn something you learned into a useful DEV post.

If you're having trouble joining the Discord, email us.