Learn Solana the Fast Way

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

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

But many Solana concepts have useful parallels with traditional development.

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

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

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

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

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

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

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

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

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

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

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

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

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

Solana starts from a different place.

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

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

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

On Solana, that proof happens through signatures.

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

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

Try it

Create your devnet wallet

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

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

A Solana wallet is an identity that can sign actions.

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

2. API calls and commands: transactions and instructions

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

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

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

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

So the rough mapping is:

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

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

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

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

Try it

Send and inspect a devnet transaction

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

The key idea is:

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

Submit your completed challenge so your progress is visible.

3. Database records and stored state: accounts

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

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

Solana also stores state, but the model is different.

State lives in accounts.

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

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

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

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

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

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

Try it

Inspect a Solana account

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

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

A place where on-chain state lives.

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

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

One table might define the asset:

name
symbol
decimal precision
total supply rules

Another table might track balances:

user ID
asset ID
amount

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

A mint defines the token.

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

That distinction matters.

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

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

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

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

Try it

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

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

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

As you do it, keep this model in mind:

The mint defines the asset. Token accounts hold balances.

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

5. Media files and metadata records: NFT metadata

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

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

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

NFTs use a similar split.

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

For that, you need metadata.

Metadata gives clients human-readable information such as:

name
symbol
description
image
attributes
collection information

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

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

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

Try it

Add metadata to an asset

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

Look for the split between:

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

The goal is to understand this:

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

6. Middleware and business rules: Token-2022 extensions

In Web2, business rules usually live in your application.

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

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

Token-2022 changes that.

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

For example, a token can be configured to:

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

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

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

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

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

Try it

Create a fee-bearing token

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

As you work through it, answer three questions:

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

The key idea is:

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

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

7. Backend logic and tests: programs and Anchor

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

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

On Solana, that logic lives in programs.

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

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

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

With Anchor, you define:

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

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

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

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

Try it

This one builds up over two short challenges.

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

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

The goal is to understand this:

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

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