DEV Community: 100 Days of Solana

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.

Epoch 2: From Reading to Creating

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

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

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

What "programmable asset" actually means

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

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

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

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

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

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

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

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

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

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

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

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

Arc 5: A token and then a name for it

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

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

At first, though, it is still pretty bare.

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

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

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

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

Arc 6: Rules the network enforces for you

Arc 6 is where Token-2022 starts to matter.

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

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

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

In Arc 6, you start combining them.

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

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

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

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

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

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

Arc 7: NFTs use the same building blocks

Arc 7 moves from fungible tokens into NFTs.

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

The difference is uniqueness.

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

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

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

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

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

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

Arc 8: Assets that carry their own behavior

Arc 8 brings the whole epoch together.

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

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

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

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

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

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

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

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

What you'll walk away with

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

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

You’ll also have written about what you built.

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

So, let's get into it!

Join us on the 100 Days of Solana journey.

What Is Token 2022 and Why Solana Built It

Vincent Jande — Fri, 15 May 2026 19:29:20 +0000

Last week, we examined the economic theories that underpin the value of Web3 tokens. This week, we are shifting our focus to the engineering reality of how these assets actually function on the Solana blockchain. As you begin building with tokens in the upcoming challenges, the nuances of account ownership and program logic will become the foundation of your development workflow.

The Library Model: Why One Program Rules

On many virtual machine blockchains, every token exists as its own independent smart contract that contains both the rules and the ledger. In that model, the ledger for a token is essentially a massive list stored inside a single contract. Solana utilizes a fundamentally different architecture by strictly separating logic from data, which is known as an account-based architecture.

Instead of requiring developers to deploy new code for every individual asset, Solana provides the SPL Token Program. This single, audited, and highly optimized program handles the logic for nearly every standard token on the network. When you create a new token on Solana, you are not deploying a smart contract. You are instead asking the Token Program to initialize a new Mint Account and designating that program as the owner. In this context, the owner refers specifically to the program that has the permission to modify the data within that account.

This standardized approach ensures that every asset follows the same predictable execution paths. This consistency is a major security feature because it reduces the surface area for logic bugs and allows every wallet or exchange to interact with any token without needing to audit unique code. The original Token Program was designed with a rigid, fixed-size account layout that handled the basics like minting and transferring, but it lacked the flexibility to adapt to the complex requirements of modern decentralized finance.

Accounts: Your Blockchain Mailboxes

To understand Solana development, you must internalize the concept that your wallet does not actually contain tokens. Instead, your wallet address acts as an authority over a specific Token Account. You can think of your wallet as a master key and the Token Account as a specialized mailbox located elsewhere on the ledger. If you wish to hold three different types of tokens, you must have three distinct Token Accounts.

Allocating space on the blockchain ledger for these data accounts requires a deposit of SOL known as the Rent-Exempt Minimum. This deposit ensures the network remains performant by preventing the accumulation of empty accounts. In modern applications, we typically use the Associated Token Account pattern. This is a deterministic way of finding a token account address using a user’s main wallet address, the token’s mint address, and the specific Token Program ID being used. Because the address is predictable, the sender can automatically initialize the mailbox for a user before sending them tokens, which solves the friction of manual account creation.

Authorities and Governance

Every token minted on Solana is governed by specific authorities that define the lifecycle of the asset. The Mint Authority is the address granted permission to generate new tokens, which directly controls the circulating supply. When a project claims its supply is hard-capped, it generally means they have renounced this authority by setting it to null. Once renounced, the supply is mathematically frozen and no further tokens can ever be created.

The Freeze Authority is a more powerful component that allows a specific wallet to lock an individual token account. A frozen account is completely immobilized and cannot receive, transfer, or burn tokens until it is explicitly thawed by the authority. While this level of control is often viewed with skepticism in purely decentralized communities, it is crucial for regulated assets, such as stablecoins, to comply with legal requirements or freeze assets involved in theft. For a developer, auditing these authorities is the first step in assessing the risk profile of any token.

The Evolution: Token 2022

As the Solana ecosystem matured, developers began hitting the ceiling of the original Token Program’s fixed layout. If you wanted to add a transfer fee or metadata to a token, there was simply no space left in the original account structure to store that information. This led to the creation of Token 2022, which is also known as the Token Extensions Program.

Token 2022 is an upgraded version of the original functionality that utilizes a more flexible data structure. This allows the program to support an expandable list of features without breaking compatibility with the original instruction set.

Transfer Fees: This extension allows projects to implement protocol-level fees without custom token logic. A configurable fee can be withheld from transfers and later withdrawn by the designated authority, allowing projects to generate revenue directly from token activity.
Confidential Transfers: This extension utilizes Zero-Knowledge Proofs to encrypt balances and transfer amounts. The network can mathematically verify that a transaction is valid without ever revealing the specific numbers to the public ledger.
Transfer Hooks: This is a powerful tool for developers because it allows a mint to require that every transfer call a secondary program. This enables logic such as mandatory identity checks or automated royalty enforcement.
Native Metadata: Developers can now store names and symbols directly within the mint account. This reduces the reliance on separate metadata systems for simpler use cases and reduces the overall complexity of your code.
Permanent Delegate: This extension allows a specific authority to move or burn tokens from any account. While powerful, it is essential for institutional compliance and the recovery of assets in legal disputes.

Why This Matters for the Challenges Ahead

As you progress through the coding challenges, you will be responsible for choosing when to use the legacy Token Program and when to leverage the advanced capabilities of Token 2022. Understanding the relationship between programs and accounts will save you hours of debugging when a transaction fails due to a missing account or an unauthorized signer. You are not just learning to code, you are learning to architect on a global and parallelized ledger. The flexibility of Token 2022 represents the next chapter of Solana’s growth by shifting tokens from simple balance entries into complex and programmable financial instruments.

Keep building and pay close attention to the account constraints in your upcoming programs. The precision you apply today will be the security of the protocols you deploy tomorrow.

See you on Discord.

100 Days of Solana is a free daily coding challenge. If you have not joined yet, you can start your journey here: https://mlh.link/solana-100

Solana Writing Challenge: End of Epoch 1

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

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

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

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

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

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

Prizes

And, of course, we have prizes.

We’ll award $500 prizes in three categories:

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

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

To be eligible:

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

Use our template to get started!

Questions?

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

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

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

Arc 3 Catch-Up: Solana Transactions Explained for Web2 Developers

Matthew Revell — Mon, 11 May 2026 12:32:11 +0000

Arc 3 of 100 Days of Solana was the arc where Solana stopped being something we read from and started being something we wrote to.

Across the arc, we inspected transactions, sent SOL on devnet, built a transfer tool, tracked confirmation, and deliberately triggered failures. That shift changes how everything else fits together: accounts, programs, fees, confirmation, errors, and application state.

They all hang off one idea:

A Solana transaction is a signed request to change on-chain state.

Reading is pretty much like Web2. Writing is not.

Reading from Solana maps neatly onto things most Web2 developers already do. You ask for a balance. You fetch account data. You look up a transaction. The network answers.

Writing is different. It is closer to making a POST request that changes production data, except there is no single server receiving it.

In a Web2 app, a write usually follows a familiar path: take some input, check authorization, run logic, change state, return a result. Solana has the same broad shape, but the mechanics are different. To change state, you create a transaction: a signed, time-limited message that says which accounts are involved, which program should run, and what instruction that program should execute.

That is why a SOL transfer is such a useful first write. It is small enough to understand, but it contains the ingredients that keep showing up across Solana development: accounts, signatures, instructions, fees, confirmation, and failure modes.

Calling a program, minting a token, swapping an asset, or updating application state all build on the same foundation. The details change, but the shape remains familiar: prepare the instruction, sign the transaction, submit it to the network, and handle the result.

That was the real purpose of Arc 3: not just sending SOL, but learning Solana’s write path.

The HTTP analogy helps, until it doesn't

If you're coming from a Web2 background, the easiest on-ramp is to think of a Solana transaction as something like an HTTP request. At first, the comparison is useful. A transaction has structure, travels over the network, carries authorization, asks another system to do something, and produces a result you can inspect afterwards.

But it breaks down once you look closer.

An HTTP request is handled by an application server or backend service. A Solana transaction is validated by a network.

An HTTP request usually authenticates with a cookie, API key, or bearer token. A Solana transaction is signed with a cryptographic keypair before it leaves your machine.

And unlike a chain of separate API calls, a Solana transaction is atomic. If one instruction fails, the whole transaction fails. You do not get partial success where step two worked but step three did not.

There is also a freshness constraint. Every transaction includes a recent blockhash, which means it is only valid for a short window before the network refuses it.

So maybe it's better to think of it like this:

A Solana transaction is a signed message that says: “Run these instructions, against these accounts, before this short validity window closes.”

That makes it different from a normal API request. It is authorized before it is sent, it only works for a short window, and it succeeds or fails as one unit. On Solana, that short window is enforced with a recent blockhash, which stops old transactions from being replayed forever.

What's actually inside a transaction

Transactions can feel abstract because most of the time we only see the receipt: a signature, a success message, or an Explorer link.

But a transaction is not just a receipt. It is the actual message sent to the network.

If you have ever opened your browser’s network tab and inspected a request, the idea is similar. You stop seeing “the button worked” and start seeing the parts underneath: who sent the request, what data went with it, what endpoint it hit, and what the server returned.

Solana gives us the same kind of visibility. Using solana confirm -v and Solana Explorer, you can open up a transaction and see the main pieces:

Signatures: proof of who authorized the transaction.
Account keys: the accounts the transaction reads from or writes to.
Recent blockhash: the freshness check that helps stop old transactions being replayed.
Instructions: the operations the transaction asks a program to run.

The account list is not just a bag of addresses. Its ordering matters. The transaction header uses position to work out which accounts are signers, which are writable, and which are read-only.

You do not need to memorize the whole transaction format before building anything. The important thing is to see that a transaction is structured data, not magic.

It has authorization. It has inputs. It has instructions. It has constraints.

Once you have seen that structure once, a transaction stops feeling like a mysterious blockchain blob and starts looking more like something a developer can inspect, reason about, and debug.

Why a simple SOL transfer teaches so much

A SOL transfer is a good first write because it is small enough to follow, but complete enough to show the full pattern.

In Web2 terms, it is like starting with the simplest useful endpoint: POST /transfer. You are not building the whole application yet, but you are exercising the important pieces of a write path.

A single SOL transfer includes:

a fee payer, who pays for the transaction
a source account, where the SOL comes from
a recipient public key, where the SOL is going
an amount, measured in lamports
a System Program instruction, which performs the transfer
a signature, which authorizes it
an Explorer record, which proves what happened

That is a lot of Solana in one action. It shows accounts, signatures, instructions, fees, confirmation, and verification without needing to write a custom program first.

It also introduces an important idea for Arc 4: a public key can exist before there is an on-chain account for it. When SOL lands at a brand-new recipient, the System Program can create the account state the network will track from that point on.

That is the first hint that an “account” on Solana is not just another word for “wallet.” It is where state lives.

Wrapping a transfer in a tool

Running a transfer from the CLI proves the basic idea. Turning it into a tool makes the pattern reusable.

In Arc 3, that tool was a small Node.js command-line app built with @solana/kit, the newer Solana JavaScript SDK. You will still see plenty of tutorials using @solana/web3.js, so it is useful to know both names.

The tool did the same things a good wrapper around any important operation should do:

accept a recipient and amount
validate the input
check the sender’s balance
build and sign the transaction
submit it to devnet
print an Explorer link as a receipt

That shape should feel familiar. If you have ever wrapped a payment API, built an internal CLI, or added guardrails around a production write, you already know the pattern: validate, prepare, execute, return something the user can trust.

The difference is what sits underneath.

This tool was not sending a normal API request to one company’s backend. It was creating a signed transaction and submitting it to a decentralized network.

That was the practical bridge in Arc 3: moving from “I understand what a transaction is” to “I can build something that uses one.”

Confirmation is a product decision

One of the most useful realizations in Arc 3 was that “success” on Solana is not a single moment.

A transaction moves through commitment levels: processed, confirmed, and finalized. Each stage tells you something different about how far the transaction has moved through the network.

For developers, that is not just blockchain terminology. It affects the product experience.

If you are building a wallet, payment flow, marketplace, game, or developer tool, you have to decide what the user sees after they click the button.

Do you show “pending” as soon as the transaction is submitted? Do you show success once it is confirmed? Do you wait for finalization before enabling the next action? Do you include an Explorer link so the user can verify the result themselves?

A signature is a receipt, but not an explanation. Good tools show progress.

That is why the Arc 3 tool added confirmation feedback. It helped turn the gap between “sent” and “settled” into something visible, understandable, and useful.

Failed transactions are still real transactions

The most useful thing we did in Arc 3 was break things on purpose.

We tried sending from an empty wallet. We tried sending more SOL than the wallet held. We skipped preflight checks to push a doomed transaction onto the network anyway. Then we inspected what came back: CLI output, Explorer pages, logs, and transaction metadata.

The lesson is important for Web2 developers: on Solana, a failed transaction is still a real transaction attempt.

If signature verification succeeds, the transaction can still pay the base signature fee — 5,000 lamports per signature, before any optional priority fee — even if execution later fails. Validators still did work. The chain still attempted the change. The intended state change failed, but the fee was still real.

That reframes error handling.

You validate before signing. You simulate before submitting. You read structured errors like meta.err and InstructionError. You watch for blockhash expiry. You design flows that avoid wasting user fees on failures you could have caught earlier.

In Web2, error handling is mostly about user experience and reliability. On Solana, it is also part of the cost model.

What Arc 3 sets up

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

Transactions are how Solana changes state. They are signed before submission. They contain instructions. Those instructions act on accounts. Confirmation happens in stages. Failed transactions can still cost money.

That leads directly to the next question:

If transactions change state, where does that state live?