DEV Community: 100 Days of Solana

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?

On Solana, the answer is accounts.

That is where Arc 4 goes next: how state is stored, who owns it, and how programs interact with it.

Use this post as the map, revisit the Arc 3 challenges whenever you want the hands-on version, and jump into Arc 4 from here.

Join us on the 100 Days of Solana journey!

How Web3 Tokens Get Their Value

Vincent Jande — Thu, 07 May 2026 18:03:23 +0000

Someone in the 100 Days of Solana community asked a question last week that needs to be addressed: "What gives SOL its value?"

You have been using SOL in every challenge. You airdropped it, checked your balance, and you are about to start sending it in Arc 3. But where does the value actually come from? Is it just numbers on a screen?

I understand why people think that. Let’s break it down.

Liquidity: Where price comes from

The first thing to understand is that for a token to have purchasing power, there needs to be liquidity. This means there are people or pools willing to trade real assets, such as fiat or stablecoins, for that token. That liquidity is what allows a market price to exist.

Think of it like converting currencies at an airport. You hand over dollars, and you get euros. The value isn't created in that moment; it is a transfer of value from one form to another. In Web3, liquidity is the bridge that connects digital assets to the broader economy.

Different tokens, different sources of value

Not all tokens work the same way. Understanding the types helps you see where the value sits.

Native Tokens: SOL is required to pay transaction fees, stake with validators, and interact with applications. As usage of the network grows, the demand for these specific functions can increase the demand for SOL.
Stablecoins: These are often pegged to a currency like the US dollar. They maintain this peg through reserves and market mechanics. Issuers like Circle hold cash and bonds so you can redeem USDC for dollars.
Utility Tokens: These provide access to specific services, such as in-game items or decentralized file hosting. The token has value because the service it unlocks is useful to someone.
Governance Tokens: These provide voting power. Holding governance tokens for a protocol allows participation in decisions about fees, features, or treasury management.
Meme Tokens: These often derive value from community and attention. While they may begin as jokes, they can build large social networks.

The Solana-Specific Engine

Beyond general categories, Solana has unique technical mechanics that influence its economy:

The Cost of State (Rent) On Solana, storage is not free. Every time you create an account or deploy a program, you must deposit a minimum amount of SOL to make that account Rent Exempt. This SOL is held in the account to keep it active. While it isn't permanently removed, it is temporarily locked, which can reduce circulating liquidity as the ecosystem grows.
The Burn Mechanism Solana has a built-in "fee burn" where 50% of every base transaction fee is permanently destroyed. However, Solana also has inflation (new SOL issued to validators to secure the network). The net effect on supply depends on how much network activity (burn) occurs versus the rate of new issuance.
Efficiency via Proof of History (PoH) Solana’s design enables fast, low-cost transactions (settling in roughly 400ms). This can make certain applications, like high frequency DeFi or real time payments, more efficient. This efficiency increases the usefulness of the network, which in turn supports the value of its native token.

Liquidity pools: How tokens stay tradeable

In Web3, we often use liquidity pools instead of traditional order books. A liquidity pool is a smart contract holding two tokens, such as SOL and USDC. Prices are set automatically using mathematical formulas rather than matching individual buyers and sellers like a traditional exchange.

People who deposit tokens into these pools are called liquidity providers. They put in a balanced value of both tokens and earn a portion of the trading fees. This is how decentralized exchanges like Raydium or Orca function. When more people buy SOL from the pool, it becomes scarcer in that pool, and the price rises automatically.

Is it real?

Value in Web3 comes from the same place all value comes from: utility and demand.

SOL is useful because the network processes thousands of transactions per second for very low costs. USDC is useful because it allows for digital dollar movement globally. DeFi protocols are useful because they provide financial tools without traditional intermediaries.

The infrastructure is different from traditional finance, but the principles are the same. Value frequently follows utility.

What this means for you

You have been working with DevNet SOL, which has no monetary value. However, the mechanics are identical to Mainnet. The RPC calls, the wallet interactions, and the transaction flows are all the same.

In Arc 3, you start sending transactions and moving "simulated value." Understanding how that value flows, even on a test network, makes you a better builder. You are practicing the exact same movements you will eventually perform on Mainnet. Whether you end up creating a payment system, a DeFi protocol, or something entirely new, this technical foundation is where it starts.

Keep building. See you on Discord.

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

AMA with Solana's Brianna Migliaccio

Matthew Revell — Wed, 29 Apr 2026 13:44:10 +0000

If you're new to Solana—or Web3 and blockchain more broadly—you almost certainly have questions.

That’s expected.

Web3 works under different assumptions to traditional web and mobile development.

Plus, there’s a whole new set of concepts and terminology to get familiar with.

So let’s make that easier.

Join us live

📺 https://twitch.tv/mlh

🗓 Wednesday, April 29

🕛 12:00 Eastern / 17:00 UK / 21:30 India

Come ready with your questions.

And if you can’t make it, we’ll share the highlights here on DEV.

Want to learn more about Solana? Join the 100 Days of Solana challenge >

Why Web3 Exists and Why Solana Matters

Vincent Jande — Tue, 28 Apr 2026 18:19:40 +0000

You trust middlemen every single day. You probably don't even think about it.

Your bank holds your money. Instagram holds your followers. Spotify holds your playlists. Google holds your emails. Every service you use, someone else is in control. They control access to your data and assets within their systems and policies.

In our current digital landscape, our "ownership" is essentially a managed service. Whether it's a financial institution or a social media platform, your access depends on the stability and policies of the provider. Web3 is the movement to change this, to build an internet where you actually own your digital assets and data.

To make this vision a reality, we need a foundation that doesn't rely on a central boss. This is precisely what blockchain was designed to provide.

So what is a blockchain?

Imagine a notebook that thousands of people have a copy of. Every time someone writes something in it, every copy is updated simultaneously, provided the network agrees the entry meets specific conditions. You can't rip out a page, change what was already written, or claim ownership over the whole thing.

That's the core idea of a blockchain. It is a shared record that functions without a central boss. Once information is recorded, it remains there permanently because the system is designed to prevent anyone from tampering with the history. Instead of trusting a single company to keep the records straight, the system relies on math and a network of computers reaching a consensus.

While this describes the initial "open and ownerless" concept, the technology has evolved to allow for managed variations like private, hybrid, or consortium blockchains, where specific entities or pre-selected groups control the records rather than the general public.

Why does this matter?

It shifts how we handle control and trust in our daily lives.

Moving value without traditional hurdles. Usually, sending money abroad involves a chain of banks. It can take days, involves various fees, and a single institution can decide to halt the transaction. Blockchain allows for more direct transfers that often settle much faster, bypassing many of the usual middlemen.

Agreements governed by code. Think about hiring a freelancer. Rather than relying solely on a handshake or expensive legal backing, you could use a smart contract. The agreement is programmed: when the work is verified, the payment is released automatically. This reduces the need to chase invoices or worry about payment delays.

Secure records of ownership. Most important documents, like house deeds, are stored in centralized offices. If those records are lost, damaged, or altered by error, proving what you own becomes a nightmare. Recording ownership on a blockchain provides a decentralized backup, meaning there is no single point of failure that can wipe out your proof of property.

These aren't just ideas for the future; the infrastructure to support these shifts is being built and used right now.

If it's so great, why hasn't it taken over?

To be honest, the early versions were often slow and expensive.

Bitcoin, the first major implementation, can handle roughly 7 transactions per second. Compare that to Visa, which processes around 65,000. While Bitcoin was a massive breakthrough in proving the concept of decentralized trust, it wasn't originally designed for high-speed, high-volume traffic.

Ethereum expanded the horizon by making the technology programmable. It allowed people to build applications and write smart contracts, but it faced similar growing pains. During busy periods, the network can get congested, causing transaction fees to spike sometimes to $50 or more. High costs like that make it difficult to use for everyday things like buying coffee or paying a small invoice.

For a while, these limitations meant the tech was mostly used for speculation. People traded tokens back and forth, not necessarily because the technology lacked potential, but because the underlying infrastructure was still catching up to the demand.

Where Solana comes in

Solana was built to address these specific bottlenecks.

While many earlier blockchains struggled with low throughput, Solana was engineered to handle thousands of transactions per second. This shift makes the technology much more practical for daily use. Instead of paying dollars in fees and waiting minutes for a confirmation, transactions on Solana typically cost fractions of a cent and finalize in under a second.

This performance is what allows for real-world applications beyond just trading. It opens the door for:

Global payment systems that rival traditional speeds.
Social platforms and games where every interaction doesn't require a massive fee.
Supply chain tracking that needs to record thousands of data points in real-time.

Solana isn't the only high-speed network available, but it has become one of the most battle-tested. With a large developer ecosystem and a growing list of products running in production, it represents a move away from theoretical potential toward actual, scalable utility.

Why you should care right now

If you are a developer, blockchain isn't a "future" skill you can indefinitely postpone. Companies are hiring for it, products are shipping on it, and those who understand the architecture now have a distinct advantage.

The best part? If you know JavaScript, you already have a solid foundation. Building on Solana doesn't mean starting from scratch or throwing away your existing knowledge. Many of the core concepts map directly to the logic and systems you already understand.

Start building

100 Days of Solana is a free, daily coding challenge designed to take you from zero blockchain experience to building functional applications.

The Format: One challenge per day.
The Goal: No prerequisites, just show up and build.
The Progress: Last week, participants set up their first wallets, funding them with test SOL, and interacting with the network. This week, participants will learn how to read the blockchain. By the end of the 100 days, you won't just have theoretical knowledge; you'll have a portfolio of real projects that demonstrate exactly what you can do.

Join 100 Days of Solana

Web3 Terminology Mapped to What You Already Know

Matthew Revell — Mon, 20 Apr 2026 17:10:05 +0000

Web3 can seem intimidating at first. And a lot of that is to do with terminology.

But once you make the connection between what you already know from web and mobile dev, for example, everything becomes a little clearer.

Here are some common Web3 terms and concepts translated into their Web2 equivalents to help you make the move.

100 Days of Solana

Want to learn Web3? Join 100 Days of Solana for free to go from curiosity to building!

Web3 Fundamentals

Let's start with the basics.

Why is it called Web3?

The idea is that this is third phase of the web.

Web 1 was the original, read-only world wide web of the 90s.
Web 2 made things two-way, so the web became participatory.
Web 3 uses blockchain technologies to make you the owner of your data, rather than the companies running websites and apps you use.

It can take a while to realize why that's important and what it means. Seeing it in action makes all the difference.

Web3 Core Pillars

To understand how this actually works, you only need to know three things:

The Blockchain: A public ledger (think of it like a very distributed database) that lives on thousands of computers at once. It’s "permissionless", meaning no one can block you from using it.
The Wallet: Your digital identity. Instead of an email and password, you use a private key stored in your wallet to prove you own your assets.
Smart Contracts: Pieces of code that live on the blockchain. They execute automatically when certain conditions are met.

But there are plenty more ideas and phrases that you'll need to get used to in order to feel fully comfortable in the Web3 world.

Making Sense of the Rest

Now that you understand the three core pieces — blockchain, wallet, and smart contracts — everything else in Web3 is really just combinations of those ideas.

The terminology can still feel unfamiliar, though. So let’s map the most common terms to things you already use as a developer.

Identity: Wallets Replace Accounts

You already know that in Web2:

users sign up
you store their credentials
you authenticate requests

In Web3, your wallet replaces all of that.

Web3	How to think about it
Wallet	Your account (but you control it, not a platform)
Public Key	Your user ID or username
Private Key	Your cryptographic identity — used to prove ownership and sign actions
Signing	Logging in / proving who you are

The key difference is simple but important:

Instead of logging in to a server, you prove who you are by signing requests with your private key.

Data: The Blockchain Is the Database

You already understand databases, APIs, and writes.

The blockchain is just a very different kind of database.

Web3	How to think about it
Blockchain	A shared, append-only database
Transaction	A write operation
Node	A server running the database
Gas / Fees	Paying for compute or writes, just like paying for API calls or cloud compute

What changes here isn’t what you’re doing but, instead, the constraints:

writes are public
writes are permanent
writes cost money

That can make you think much more carefully about what you store and when.

Logic: Smart Contracts Are Your Backend

You already write backend code that:

processes requests
enforces rules
updates data

Smart contracts do the same thing.

Web3	How to think about it
Smart Contract	Backend logic
Program (on Solana)	A deployed service
Calling a contract	Making an API request

The important shift:

You don’t control the runtime once it’s deployed.

Value: Ownership Is Built In

In Web2, ownership is just a database entry you or someone else controls.

In Web3, it’s enforced by the system itself.

Web3	How to think about it
Token	Money or API credits that aren’t tied to a single service (like Stripe balance, but portable and user-owned)
NFT	Like owning a domain name, it's a unique asset with verifiable ownership (and not just a picture of an ape)
Wallet balance	Your bank balance but without a bank controlling it

The difference:

In Web2, ownership is just a row in someone's database. In Web3, it’s enforced by the network and you can’t change it manually.

Apps: Same Shape, Different Backend

At a high level, Web3 apps still look familiar.

Web3	How to think about it
dApp	A web app
RPC endpoint	Your backend API
Explorer	A read-only database viewer
Mainnet / Devnet	Production / staging

The frontend is still yours.

The backend is now a public network.

What Actually Changes

If this all feels surprisingly familiar, that’s the point.

Much of Web3 isn't a completely new model, instead it's a new way of thinking about things you already know well. The core differences are:

You control identity (wallets instead of accounts)
You pay for writes (like calls to a paid API)
You deploy immutable logic (contracts instead of editable app code)
You rely on shared infrastructure (networks instead of owned backends)

That’s it.

The Only Way This Really Clicks

Reading helps. But it won’t fully land until you try it.

The moment you:

generate a keypair
send a transaction
see it appear on-chain

…all of this terminology stops feeling abstract.

And we're here to help with that. 100 Days of Solana is a hands-on daily coding challenge that takes you from no Web3 experience to able to build with Solana. Join free!