DEV Community: 100 Days of Solana

Understanding Program Derived Addresses: The Solana Address That Has No Private Key

Vincent Jande — Fri, 19 Jun 2026 12:23:35 +0000

Every Solana program eventually hits the same question: where do I put my data, and how do I find it again later?

Programs are stateless, so a program's data lives in separate accounts, each at an address. The moment you store something, you owe an answer to a problem databases tend to hide from you: what address does this live at, and how does the program find it again tomorrow? Program Derived Addresses are Solana's answer. The name scares people off, but the idea is mostly "an address you compute instead of remember, that only your program can control."

The problem, in code

Say each user gets a counter account. The normal way to make an account is to generate a fresh keypair and store data at its public key:

import { Keypair } from "@solana/web3.js";

const counter = Keypair.generate();
// counter.publicKey is something random, e.g. 7Hx4...9fT
// create the account at that address, write count = 0

It works. But the address is random, so nothing connects this user to that address. Tomorrow, when the user comes back to increment, how does your program find their counter? You're forced to keep a lookup table somewhere:

// the mapping you now have to store and never lose
const counters = {
  "9fYL...user1": "7Hx4...9fT",
  "B2k9...user2": "Qz1p...4dR",
  // ...times ten thousand users
};

Lose that table, lose the data, even though the accounts are right there on chain. You're storing files in a warehouse and writing the shelf number on a sticky note.

The fix: compute the address from what you already know

What if the address were a function of the user instead of random? Give a function the word "counter" and the user's public key, and it hands back a fixed address. Same inputs, same address, every time. No table.

That's a PDA. PDAs are 32-byte addresses derived deterministically from a program ID and a set of seeds. The seeds are the meaningful inputs you pick (here, "counter" + the user's key). With @solana/web3.js, the library Anchor's client uses:

import { PublicKey } from "@solana/web3.js";

const [counterPda, bump] = PublicKey.findProgramAddressSync(
  [
    Buffer.from("counter"),      // a label
    userPublicKey.toBuffer(),    // the user's pubkey
  ],
  MY_PROGRAM_ID,
);
// counterPda is the SAME every time for this user. No mapping needed.

The mapping table is gone: any time you need a user's counter, you re-derive it, and the address itself encodes who it belongs to. With Anchor you'll often skip the explicit call entirely and let the client derive PDAs from the IDL, but under the hood this is what runs.

The twist: it has no private key

Normal addresses are public keys sitting on the Ed25519 elliptic curve, and every point on that curve has a matching private key. That private key is what signs transactions. But we just hashed a counter address into existence without making a keypair, so who holds its private key?

If the hash happened to land on the curve, some stranger might, which would let outsiders sign for your program's accounts. So Solana guarantees a PDA sits off the curve, meaning no private key exists for it. That is the title: an address with no private key. It is the whole point, because it means only the program that derived it can control it.

The bump, in one example

A given set of seeds plus the program ID produces a valid off-curve address only about half the time, so the derivation includes one more input: a single byte called the bump. The search starts at 255 and counts down, hashing the seeds, the program ID, and the current bump together on each attempt until the result lands off the curve:

hash(seeds + program_id + 255) -> on curve?  try 254
hash(seeds + program_id + 254) -> on curve?  try 253
hash(seeds + program_id + 253) -> off curve! use this.  bump = 253

The bump is part of the hash from the very first attempt at 255, not something added only after a bump-less hash fails. The first value that lands off-curve, the highest one that works, is the canonical bump. findProgramAddressSync returns it as the second value, the bump above. You'll want to use the canonical bump rather than any other valid one, because the same seeds can produce different valid addresses under different bumps, and accepting any of them would let an attacker slip a counterfeit account past your checks.

In Anchor: derivation becomes a constraint

On the program side, Anchor does the derivation and the check for you. Creating the counter (storing the bump for later):

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
        seeds = [b"counter", authority.key().as_ref()],
        bump,                                  // Anchor finds the canonical bump
    )]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

Then later, validating it on every other instruction:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(
        mut,
        seeds = [b"counter", authority.key().as_ref()],
        bump = counter.bump,                   // reuse the stored bump
    )]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

Read the seeds line as a rule: this account's address must derive from "counter" and this authority's key. When the instruction runs, Anchor re-derives the address and checks that the passed-in account matches. Pass a different account and it's rejected before your code runs. The address is the proof, so there's no mapping left to tamper with. (Store the bump in your Counter struct at init: pub bump: u8.)

The difference between the two structs is the whole lifecycle: init creates the account at the derived address the first time and lets Anchor search for the canonical bump, while the plain seeds + bump = counter.bump form validates an account that already exists, reusing the stored bump so it doesn't pay to re-search.

Four things that trip people up

Seed mismatch between client and program. The seeds, their order, and their byte encoding need to match on both sides. Buffer.from("counter") in the client has to line up with b"counter" in the program, in the same position. One reordered or mistyped seed derives a different address, and the constraint rejects it. A lot of "my PDA doesn't match" bugs come down to this.
Not storing the bump. If you don't save the canonical bump at init, every later instruction has to re-derive it by searching, which burns compute for no reason. Store it once in the account and reuse it with bump = counter.bump.
Treating the rejection as a bug. When you pass the wrong account and the seeds constraint throws, that's the security model working, not a failure. The point is that only the correctly derived address gets accepted.
Deriving without the canonical bump. Other bump values can produce valid but different addresses from the same seeds. Sticking with the canonical one, which is what Anchor's bare bump and findProgramAddressSync give you by default, keeps client and program in agreement.

The payoff: a program that signs for itself

No private key means no human can sign for a PDA, so how does a program move tokens out of an escrow it owns? The runtime gives the owning program a special power: the program whose ID derived the PDA can sign for it, through invoke_signed during a cross-program invocation. The program's code becomes the authority, with no key anywhere.

That's the foundation under most escrows, vaults, and lending pools on Solana: a program holding assets no human can drain, releasing them only by its own logic. We'll go deep on invoke_signed and CPIs in the next post. For now, hold the shape: the missing private key isn't a weakness, it's what lets a program act as a trustless custodian.

TL;DR

Stateless programs store data in accounts at addresses; remembering random addresses doesn't scale.
A PDA derives the address from seeds + program ID, so you recompute it instead of storing it.
It's forced off the Ed25519 curve, so no private key exists and no outsider can sign for it.
The canonical bump (counting down from 255) is the reproducible address you'll normally use.
In Anchor, seeds + bump constraints derive and validate the account for you.
The deriving program can sign for its own PDA (invoke_signed), which is what powers escrows and vaults.

Going further

The Solana PDA docs cover derivation, the canonical bump, and the off-curve guarantee, with runnable examples on the derivation page (the "Legacy" tab is the @solana/web3.js version Anchor's client uses). The Anchor PDA guide walks through the seeds and bump constraints you'll actually write, and the full account constraints reference lists every constraint in one place.

If you're doing 100 Days of Solana, the next arc puts all of this to work, and the challenges should now read like something you already understand. Not joined yet? It's not too late: mlh.link/solana-100.

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.

The Rust You Actually Need to Write Your First Anchor Program

Vincent Jande — Sat, 13 Jun 2026 12:25:48 +0000

If you have made it this far in 100 Days of Solana, you have been working in JavaScript and on the command line. You have been calling RPC methods, building instructions, signing transactions, and reading and writing account data in JavaScript, and most recently minting and sending tokens and NFTs from the CLI. Either way, you have been driving Solana with tools that let you assign a value and move on with your life. Soon the ground shifts. You are going to open a file called lib.rs, and it is going to be Rust, and for a day or two it is going to feel like you forgot how to program.

That feeling is normal, it is temporary, and it is not a sign you are in the wrong place. Here is the thing nobody says out loud: you do not need to learn all of Rust to write Solana programs. Rust is a big language with a steep reputation, but the slice of it that shows up in an Anchor program is small and repetitive. You will see the same handful of patterns on almost every line. Learn those patterns and the wall turns back into a floor.

This post is that handful. Not a Rust course, just the parts you need to read your first Anchor program and understand what every line is doing. Next week we start Arc 9, the Anchor introduction, where this all becomes real. This week is about making the language stop being scary before you get there.

Why it feels like a wall

JavaScript is dynamically typed and garbage collected. You write const x = 5, you never tell anyone it is a number, and when you are done with it the runtime quietly cleans up. The language trusts you and sorts out the consequences at runtime, which is why a typo surfaces as undefined is not a function three minutes into a demo.

Rust is the opposite philosophy. It is compiled and statically typed, so every value has a type the compiler knows about before the program ever runs, and it has no garbage collector, so it tracks who is responsible for every piece of memory through a system called ownership. The trade is blunt: Rust makes you front-load the thinking. The compiler refuses to build until the types line up and the ownership rules are satisfied. That is why the first day feels slow. You are paying upfront for something JavaScript billed you for later, usually in production.

The reassuring part, and this is real, is that the Rust compiler is the most helpful error reporter you have ever worked with. A JavaScript bug explodes at runtime with a vague message and no map. A Rust bug stops at compile time with an error that names the file, the line, the types involved, and very often the exact fix to type. You will spend the Anchor arc reading compiler errors. Get good at reading them slowly instead of panicking at the red text, because nine times out of ten the answer is sitting right there in the message.

The anatomy of the file you are about to meet

Before the individual pieces, here is the shape of a minimal Anchor program, taken straight from the Anchor program structure docs:

use anchor_lang::prelude::*;

declare_id!("11111111111111111111111111111111");

#[program]
mod hello_anchor {
    use super::*;
    pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {
        ctx.accounts.new_account.data = data;
        msg!("Changed data to: {}!", data);
        Ok(())
    }
}

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

#[account]
pub struct NewAccount {
    data: u64,
}

Every Anchor program you write next week is a variation on those four blocks. The rest of this post walks through the Rust you need to read them without flinching.

1. `use` and the import line

use anchor_lang::prelude::*;

This is the Rust version of an import. use brings names into scope so you do not have to write the full path every time, and the * is a glob that pulls in everything from Anchor's prelude, a curated bundle of the types and macros nearly every program needs. It is the same instinct as importing from a package in JavaScript, just with a :: path separator instead of a dot and slashes. When you later see errors about a type "not found in this scope," a missing use line is the usual cause. You can read more in the Rust book chapter on packages and modules.

2. Macros: the lines with `!` and `#[...]`

This is the single biggest "what am I looking at" moment for a JavaScript developer, so it gets the most space.

Rust has macros, which are code that writes code at compile time. They are not functions. You can spot them two ways. A ! after a name, like declare_id!(...), msg!(...), or require!(...), means a macro call. And the bracketed attributes sitting above things, like #[program], #[derive(Accounts)], and #[account], are also macros, the attribute kind, that transform the item directly below them.

Why this matters: Anchor is mostly macros. The whole point of the framework is that those attributes expand, at compile time, into the hundreds of lines of account-validation and serialization boilerplate that a raw Solana program makes you write by hand. The Anchor docs describe the four you will see constantly:

declare_id! sets your program's on-chain address.
#[program] marks the module that holds your instruction handlers. Each public function inside it becomes a callable instruction.
#[derive(Accounts)] goes on a struct to declare the list of accounts an instruction needs, and generates the validation for them.
#[account] goes on a struct to mark it as a custom account type your program stores data in. Among other things it stamps an 8-byte discriminator on the account so the program can later prove the account is really one of its own.

You do not need to know how to write a macro. You need to recognize that when you see #[derive(Accounts)], an enormous amount of code you did not write is being generated for you, and that this is the framework doing its job. Treat the attributes as configuration you are declaring, not logic you are reading. The Rust book's macro chapter is there if you get curious, but it is genuinely optional for the Anchor arc.

3. Structs: your data shapes

#[account]
pub struct NewAccount {
    data: u64,
}

A struct is just a named bundle of fields, the same idea as a plain JavaScript object with a fixed shape, except the shape is declared and the compiler enforces it. NewAccount has one field, data, of type u64, an unsigned 64-bit integer. You will define a struct for every kind of account your program stores, and another struct for every instruction's account list (those are the #[derive(Accounts)] ones). When you read an Anchor program, structs are where you learn what data exists and what each instruction touches.

A note on number types, because JavaScript hides this from you. JavaScript has one number. Rust makes you pick: u64 is an unsigned (non-negative) 64-bit integer, i64 is signed, u8 is a byte, and so on. On Solana, u64 is everywhere because token amounts and counts are 64-bit. Picking the type is part of declaring your data, and it is why a counter's field is count: u64 and not just "a number."

4. `pub`: who can see this

pub means public. By default everything in Rust is private to its module, and pub opts an item into being visible outside it. In Anchor you will see pub fn on instruction handlers (the framework needs to call them from outside the module) and pub on struct fields you want readable. It is access control at the language level, closer to export in JavaScript modules than to anything in a plain object.

5. Functions and the return type

pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {
    // ...
    Ok(())
}

fn declares a function. The parameters list their types after a colon, data: u64, the same "name then type" order you have already seen in the struct. The part that is new is -> Result<()>, the return type, which leads straight into the most important Rust concept for the week ahead.

6. `Result`, `Ok`, and the `?` operator: error handling without try/catch

JavaScript handles errors by throwing and catching. Something fails, it throws, and somewhere up the stack a try/catch maybe deals with it, or maybe it crashes. Nothing in the type system forces you to handle it.

Rust has no exceptions. Instead, a function that can fail returns a Result, a type that is either Ok(value) for success or Err(error) for failure. Every Anchor instruction handler returns Result<()>, which reads as "this either succeeds with nothing meaningful to return, the empty (), or it fails with an error." That is why every successful handler ends with Ok(()): you are explicitly returning the success case. The Anchor docs note that all Anchor instruction handlers return this Result type.

The companion to Result is the ? operator, and it is worth learning early because it is everywhere. When you call something that returns a Result and write a ? after it:

let counter = something_that_can_fail()?;

it means "if this is Ok, unwrap the value and keep going; if it is Err, stop this function right now and return that error to the caller." It is the same job a try/catch does, compressed into one character, and it is how Anchor programs bubble failures up to the runtime cleanly. When you see ?, read it as "this line might bail out early, and that is intentional."

You will also meet Option, the cousin of Result: it is Some(value) or None, and it is how Rust represents "this might be absent" instead of JavaScript's null or undefined. The reason Rust almost never has null-pointer surprises is that absence is a type you are forced to handle, not a landmine.

7. References and `&mut`: the ownership stuff

Here is the concept with no JavaScript equivalent, and the one that produces the most head-scratching. Rust tracks ownership of data. Every value has one owner, and when you want to let other code use a value without handing over ownership, you lend it out with a reference, written &. A plain & is a read-only borrow. &mut is a mutable borrow, meaning "I am lending you this and you are allowed to change it."

You will see this constantly in handlers:

let counter = &mut ctx.accounts.counter;
counter.count = 0;

Read &mut ctx.accounts.counter as "get a mutable borrow of the counter account so I can write to it." Without &mut, you would have a read-only view and the compiler would reject the assignment. The rule the compiler enforces, and the source of most early borrow-checker errors, is that you can have many readers or one writer, but not both at once. That sounds restrictive until you realize it is the rule that makes whole categories of bugs impossible.

For the Anchor arc you do not need the deep theory. You need to recognize that & means "borrowed, look but do not take," &mut means "borrowed, allowed to change," and that when the compiler complains about borrowing it is protecting you from two pieces of code stepping on the same data. When you genuinely want to understand it, the ownership chapter of the Rust book is the clearest explanation written, and the Pubkey types being small and Copy (cheap to duplicate, so you often pass them by value) is a footnote you will appreciate later.

8. Custom errors with enums

When your program needs to reject something with a meaningful reason, you define an error type as an enum, a type that is one of a fixed set of named variants:

#[error_code]
pub enum CounterError {
    #[msg("The counter has reached its maximum value.")]
    Overflow,
}

An enum in Rust is more powerful than a JavaScript constant list, but for now read it as "a closed set of named options." The #[error_code] attribute is Anchor wiring it into the program's error system, and the #[msg(...)] lines are the human-readable strings that show up in logs when that error fires. You then raise one with the require! macro or by returning Err(...). The Anchor errors guide covers the full pattern, and you will use it the moment your program needs to say no to bad input.

Putting it together

Read that minimal program one more time and notice you can now name every piece. use pulls in Anchor. declare_id! is a macro setting the address. #[program] is an attribute macro marking the handler module. initialize is a public function taking a Context and some data, returning a Result, ending in Ok(()). The #[derive(Accounts)] struct declares the accounts. The #[account] struct declares the stored data shape, with a u64 field. None of it is mysterious anymore. It is the same eight ideas, arranged.

That is the whole trick this week. You are not learning Rust the way a systems programmer learns Rust. You are learning to read a specific, repetitive dialect of it, and the vocabulary is small: imports, macros, structs, pub, functions, Result and ?, references, and enums. Every program in the arc ahead is built from those.

How to actually get through the week

A few habits that will save you real time.

Read the compiler errors top to bottom, slowly. Rust errors are long because they are thorough, not because they are angry. The first error is usually the real one; later errors are often just fallout. Fix the top one, recompile, repeat.

Compile early and often. Do not write thirty lines and then build. Write a few, run anchor build, see if it is happy, continue. Short feedback loops turn a scary language into a conversation.

When the borrow checker fights you, stop and ask who owns this and who is borrowing it, rather than randomly adding and removing & until it builds. The error message almost always tells you which rule you broke.

And keep one tab open on the Anchor program structure page and one on the Rust book. You will not read either cover to cover. You will look up exactly the thing in front of you, which is the right way to learn a language you are using rather than studying.

Next week the challenges move into Arc 9, the Anchor introduction, and these blog posts move with them. We leave the language topic behind here, not the program itself, and dig into Anchor properly: how accounts really work, what a Program Derived Address is and why it changes everything, and how the constraint system turns a struct into a security model. The daily challenges keep going as always; it is just this post's focus on the Rust language that wraps up today. For now, the goal is smaller and more important. Open lib.rs, recognize the pieces, and let the compiler teach you. You already did the hard part by getting here.

And if you have not joined the challenge yet, this is the moment. We are about to start writing real Solana programs, which is the part everything so far has been building toward. Jump in at mlh.link/solana-100 and build it with us.

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.

Fungible and Non-Fungible Tokens on Solana: Same System, Different Rules

Vincent Jande — Fri, 29 May 2026 18:40:51 +0000

If you have been following the 100 Days of Solana challenges, you have already worked with tokens. You created mints, set up token accounts, transferred SOL, and explored token extensions. But there is a distinction that comes up constantly in web3, and understanding it properly will change how you think about everything you build going forward.

Fungible and non-fungible tokens. You have probably heard these terms before, especially NFTs. But what do they actually mean on Solana, and how does the same token system handle two very different concepts?

What makes something fungible

Fungible just means interchangeable. One unit is identical to another unit. If I have 10 USDC and you have 10 USDC, ours are exactly the same. It does not matter which specific USDC tokens I hold because they are all worth the same and behave the same way. We could swap them and nothing changes.

This is how most things you are used to work. A dollar bill is fungible. A liter of petrol is fungible. One unit of SOL is the same as any other unit of SOL. When you built token transfers in the challenges, you were working with fungible tokens. You did not need to care about which specific tokens moved, just how many.

Fungible tokens are used for currencies, stablecoins, utility tokens, governance tokens, loyalty points, in-game currencies, and anything where the quantity matters more than the individual unit.

What makes something non-fungible

Non-fungible means unique. Each token is different from every other token, even if they come from the same collection. If I have NFT #42 from a collection and you have NFT #87, those are not interchangeable. They might have different images, different properties, different rarity, or different utility.

Think of it like event tickets. Two tickets to the same concert are not the same if one is front row and the other is in the back. They came from the same event, but each one is distinct.

Non-fungible tokens are used for digital art, collectibles, membership passes, certifications, domain names, gaming items, real estate deeds, event tickets, and anything where the individual item matters more than the quantity.

How Solana handles both with the same system

This is where Solana does something interesting. On some blockchains, fungible and non-fungible tokens are completely separate systems with different standards and different smart contracts. On Solana, both run through the same Token Program (or the newer Token Extensions program, also called Token-2022).

The difference comes down to two configuration settings: decimals and supply.

A fungible token has a mint initialized with multiple decimals (typically 6 or 9) and a supply far greater than one. You can mint millions of fractional units from the same mint, and they are all interchangeable.
A non-fungible token is a mint initialized with exactly 0 decimals, where exactly one token is minted and the mint authority is then permanently revoked.

That second part is worth being precise about, because there is no "maximum supply" field you set when you create a base SPL mint. A mint has a supply value that simply increments every time you mint into it. You create the mint with 0 decimals, mint exactly one token to a token account, and then set the mint authority to None. Revoking the authority is what locks the total supply at 1 forever, guaranteeing that no more units of this specific token can ever be printed.

Same program, same mint account layout. The rules are enforced purely by how you configure the mint and what you do with the mint authority.

One nuance: at this level you have created a non-fungible token. Wallets and marketplaces do not yet recognize it as an "NFT" in the way you would see it on a marketplace. That recognition comes from the metadata and standard layer, which is what we cover next.

The role of metadata

If a non-fungible token is just a mint with a supply of one, how do you know what it actually represents? How do you attach an image, a name, or specific traits to it?

This is where metadata comes in. On-chain, a token mint is just a state account holding configuration details and balances. The metadata gives it context.

The long-standing approach is the Metaplex Token Metadata standard, which creates a separate metadata account cryptographically linked to the token mint via a Program Derived Address (PDA). This account holds the token's name, symbol, and a URI pointing to an off-chain JSON file containing the image and attributes. That JSON is typically stored on decentralized storage like Arweave or IPFS, though some projects use centralized hosting such as AWS S3.

Token Metadata is still widely used and is not deprecated. Interestingly, a large share of assets minted through it today are actually fungible tokens, since it is also the common way to give a fungible mint a name, symbol, and icon.

For new NFT projects specifically, the current recommended standard is Metaplex Core. Core uses a single-account design, storing all of an asset's data in one account instead of the separate mint, metadata, and token accounts the older model required. That cuts minting cost dramatically (on the order of 80 percent cheaper than Token Metadata) and ships with built-in features like enforced royalties and a plugin system for custom behavior. If you are starting a new NFT collection today, Core is usually where you should look first.

There is also the Token Extensions (Token-2022) path. By enabling the MetadataPointer and TokenMetadata extensions, you can store the name, symbol, and URI directly inside the mint account itself. The pointer says where the metadata lives, and the metadata extension holds the actual fields. In practice this is used most often for fungible and utility tokens, letting a stablecoin or reward token carry a native icon and tracking data without a separate metadata account or any cross-program coordination at creation.

So the honest map of the landscape is: Token Metadata (legacy, still common, heavily used for fungibles), Core (the modern recommendation for new NFTs), Token-2022 metadata extensions (great for fungible and utility tokens), and compressed NFTs for high-volume cases, which we will get to in a moment.

For fungible tokens, metadata is simple. You usually just need a name, symbol, and maybe an icon. For non-fungible tokens, metadata can be extensive because each token is unique and needs its own description, image, and properties.

Token accounts work the same way

Whether you are holding a fungible token or a non-fungible one, you need a token account for it. This is the same concept you learned in the challenges. Your wallet needs an Associated Token Account (ATA) for each mint you want to hold.

For fungible tokens, your token account has a balance that can go up and down as you send and receive tokens. For non-fungible tokens, your token account has a balance of exactly one. You either have it or you do not.

The mechanics are identical. Creating the account, paying rent, transferring tokens. The same code patterns you have been writing in the challenges apply to both. (Metaplex Core is the one exception worth noting, since its single-account model does not use a separate token account in the same way, but the fungible side and classic NFTs both follow the familiar ATA pattern.)

Editions, collections, and scale

Not every NFT is a complete one-of-one. Sometimes you want to create multiple copies of the same item but still have each one be individually trackable. Think limited edition prints. There are 500 of them, each one is numbered, but they all share the same artwork.

In the Token Metadata standard, this is handled through editions. A master edition can produce a set number of prints. Each print is its own mint with its own token, but they are all linked back to the original master edition.

Collections group related NFTs together. A collection is itself an NFT that acts as a parent. Individual NFTs reference the collection in their metadata, which is how marketplaces know that 10,000 different mints all belong to the same project.

Here is an important practical point that trips people up. Editions and one-mint-per-item NFTs do not scale cheaply. Each one is a real account that carries rent. So if your goal is something like 1,000 identical-but-individually-owned event tickets, minting a thousand separate full NFTs gets expensive fast.

For that high-volume case, the modern answer is compressed NFTs (the Metaplex Bubblegum standard). Compressed NFTs store ownership data in a Merkle tree rather than in a full account per token, which makes it possible to mint thousands or even millions of individually owned, transferable assets at a tiny fraction of the cost. This is the dominant approach for large drops on Solana today, and it is exactly what you would reach for in the 1,000-ticket scenario.

So the decision for "many of the same thing" is really: a handful of numbered prints can use editions, but anything at real scale should use compression.

Fungible tokens with NFT properties

The Token Extensions program blurs the traditional line between fungible and non-fungible tokens in powerful ways:

Non-Transferable Tokens: By initializing a fungible mint with the NonTransferable extension, you create assets that are locked to the recipient's wallet the moment they are minted. If a user earns 50 reputation points, those points are structurally fungible but behave like "soulbound" credentials because the runtime blocks any transfer instruction.
Mint-Linked Metadata: Before Token Extensions, detailed metadata was largely reserved for NFTs via Metaplex. Now, you can inject rich metadata directly into a fungible utility token or stablecoin mint, allowing wallets to display custom icons and tracking data natively.
Transfer Hooks: You can attach a custom program to a fungible token mint that executes additional logic every time a transfer occurs. A fungible token that checks an allowlist or verifies a KYC credential before allowing a transfer begins to behave like a restricted real-world security, changing its economic behavior entirely through code.

The categories are not as rigid as they seem. Solana gives you the building blocks and you decide how to combine them.

When to use which

If you are building something where every unit is the same and users care about quantity, use a fungible token. Currencies, points, credits, governance votes.

If you are building something where each item is unique and users care about the specific item they hold, use a non-fungible token. Art, collectibles, certificates, tickets, identity documents. For a brand-new collection, start with Metaplex Core. For high-volume drops, reach for compressed NFTs.

If you are building something in between, like a limited-edition with 100 copies or a membership tier with different levels, look at editions and collections, or explore how Token-2022 extensions can give you the behavior you need.

The good news is that the skills you are building in these challenges apply to all of it. The mint, token account, and transfer patterns are the same regardless of whether you are working with fungible or non-fungible tokens.

What is coming next

The upcoming challenges will take you deeper into how NFTs work on Solana, how to mint them, how metadata is structured, and how collections come together. Understanding the foundation covered here will make those challenges click faster.

Keep building. See you in the Discord.

100 Days of Solana is a free daily coding challenge: https://mlh.link/solana-100

Web3 Apps You Can Build With Token Extensions

Vincent Jande — Fri, 22 May 2026 20:07:47 +0000

In our previous articles, we covered how Web3 tokens get their value and broke down the new standards in What is Token 2022 and why Solana built it. You understand authorities, token accounts, and the extensions available.

Now the question is what you actually build.

Token extensions are building blocks for real products. Each extension solves a specific problem. By leveraging Token 2022 via modern client libraries, you can build applications from frontend or backend scripts that would have required custom smart contracts before.

Here are some app ideas, the extensions they use, and the tools to start building them.

1. Creator Subscription Platform

Subscribers hold a token that grants monthly access to exclusive content. The token cannot be resold or moved between wallets.

Extensions: Non-transferable tokens prevent resale; metadata stores the creator name, tier, and subscription period.

How it works: Create one mint per creator per subscription period, one for "Creator X - January 2026," another for February. When a user subscribes, bundle a USDC payment with a non-transferable token mint into a single atomic transaction.

Use one mint per period because Token-2022 metadata is mint-level, every holder of a given mint reads the same expiry. Gating access is then a direct read of the period from the mint's on-chain metadata against the current date.

To reclaim or burn subscription tokens directly, add PermanentDelegate at mint creation. The extension itself can never be removed once the mint is initialized, though the delegate authority can be rotated or set to None via SetAuthority.

Tools: @solana/kit, @solana-program/token-2022, Next.js or React.

2. Loyalty Rewards Program

A business issues loyalty points as tokens. Customers earn points on purchases and redeem them for discounts.

Extensions: Non-transferable tokens keep points tied to the customer; the business retains mint authority to issue new points; metadata displays the brand.

How it works: Each business gets its own token mint. The backend mints points directly into the customer's token account on purchase events. Customers connect their wallet to a redemption portal to spend points.

On-chain identity here is pseudonymous, not private, wallet balances and minting activity are visible to anyone. Non-transferability stops third parties from trading or seizing the points, but doesn't hide them from view.

Tools: @solana/kit, @solana-program/token-2022, Node.js, React, Solana Pay.

3. Regulated Investment Token

A real estate company tokenizes a property. Only verified investors can hold the token, and the company needs a way to freeze accounts and recover tokens if compliance requires it.

Extensions: Default account state can be set to frozen so new holders start out locked until KYC clears. Freeze authority handles ongoing compliance actions, like freezing an account that falls out of good standing. A permanent delegate provides a recovery path for legal scenarios. Metadata stores property details and links to legal documentation.

How it works: New investor token accounts start frozen and are thawed after the investor passes KYC. The freeze authority can re-freeze any account later if compliance requires it, and the permanent delegate handles court-ordered recovery if it ever comes to that.

Tools: @solana/kit and @solana-program/token-2022 for the mint, freeze actions, and delegate operations, plus a KYC provider API for investor verification.

4. In-Game Currency with Transaction Fees

Players earn an in-game currency through gameplay and trade it with each other. The studio automatically collects a small fee on every user-to-user transfer to generate ongoing revenue from the game economy.

Extensions: Transfer fees collect a percentage on every token movement; metadata handles branding like names, icons, and descriptions; mint authority is retained so the studio can inject new currency into the economy via gameplay achievements.

How it works: Fees are configured at mint creation and collected automatically on token transfers with no custom program or market smart contract required. When players send tokens to each other, the configured fee is withheld directly inside the recipient's token account.

Because fees accumulate quietly inside thousands of individual player accounts, the studio's withdraw-withheld authority can periodically collect these withheld amounts and pool them into a central treasury wallet, without touching player balances.

Tools: @solana/kit, @solana-program/token-2022, a game client SDK, and an administrative backend.

Patterns to Notice

@solana-program/token-2022 is often all you need. For loyalty, subscriptions, in-game currencies, and yield-bearing wrappers, you can usually compose instructions against it from @solana/kit and skip Rust. Reach for Anchor when you need to build custom programs or manage complex state logic that standard extensions don't cover.

Plan compatibility before mint creation. Not every extension pairs with every other extension. Some combinations are blocked because their behaviors conflict (for example, anything that gates or modifies transfers tends to clash with non-transferability). Most extensions can't be added after mint creation, so check the compatibility matrix in the Token-2022 docs before committing to a design.

"No Rust required" is not "no centralized authority required." Permanent delegate, freeze authority, mint authority, and withdraw-withheld authority are centralized controls encoded in extension config. If any are live on your token, make sure to state them clearly in your project's docs or UI.

Start thinking about what you want to build

You have the fundamentals. The app ideas above are starting points, take one, modify it, make it your own.

Keep building. See you on Discord.

100 Days of Solana is a free daily coding challenge: https://mlh.link/solana-100

$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.

DEV Community: 100 Days of Solana

Understanding Program Derived Addresses: The Solana Address That Has No Private Key

The problem, in code

The fix: compute the address from what you already know

The twist: it has no private key

The bump, in one example

In Anchor: derivation becomes a constraint

Four things that trip people up

The payoff: a program that signs for itself

TL;DR

Going further

Arc 8 Catch-Up: Middleware Inside the Token

Token rules should not depend on every app remembering them

Transfer fees are enforced by the mint

The fee lifecycle is transfer, withhold, withdraw

Composability means extensions share the same mint

Interest is a view, not a background job

Reading mint configuration is part of building

Non-transferable tokens are useful because they fail

Token-2022 is configuration, but not casual configuration

Writing turns extensions into patterns

What Arc 8 sets up

Arc 7 Catch-Up: Building NFTs from First Principles

NFTs are not separate from tokens

Metadata turns a token into something recognizable

An NFT collection is an on-chain relationship

Provenance is something you can inspect

Mutability is a design choice

NFTs are records with ownership, display, and history

Writing forces the model to become simple

What Arc 7 sets up

Arc 6 Catch-Up: Designing Tokens That Enforce Rules

Extensions are asset features, not app features

Interest-bearing tokens make display different from storage

Extensions can be composed

Access control can live at the token level

Credentials need different rules from currencies

Reading configurations matters as much as creating them

Token design is product design

Writing and sharing made the combinations clearer

What Arc 6 sets up

The Rust You Actually Need to Write Your First Anchor Program

Why it feels like a wall

The anatomy of the file you are about to meet

1. use and the import line

2. Macros: the lines with ! and #[...]

3. Structs: your data shapes

4. pub: who can see this

5. Functions and the return type

6. Result, Ok, and the ? operator: error handling without try/catch

7. References and &mut: the ownership stuff

8. Custom errors with enums

Putting it together

How to actually get through the week

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

Tokens are incentive systems with stronger guarantees

A mint defines the token

Token-2022 makes the token itself more expressive

Associated Token Accounts are the default balance bucket

Transfer fees move marketplace logic into the token program

Non-transferable tokens are useful because they fail

The lifecycle is the skill

Building in public is part of the work

What Arc 5 sets up

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

Accounts are where state lives

The owner field is the security model

Programs are accounts too

Reading an account is like opening a file

Raw bytes are where this gets real

The System Program is the account clerk

Block explorers are blockchain DevTools

Writing helps the model settle

What Arc 4 sets up

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

Reading from Solana feels familiar

A wallet balance is just the first query

A dashboard turns reads into something useful

Accounts are not tables, but the database analogy helps

Storage has a price tag

1. `use` and the import line

2. Macros: the lines with `!` and `#[...]`

4. `pub`: who can see this

6. `Result`, `Ok`, and the `?` operator: error handling without try/catch

7. References and `&mut`: the ownership stuff