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

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

Tópico: Arc 5 Catch-Up: Solana Token Fundamentals Explained for Web2 Developers
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
Arc 5 of 100 Days of Solana opened Epoch 2 by moving from foundation work into programmable assets.

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

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

The whole arc hangs off one idea:

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

That is the big shift for Web2 developers.

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

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

Tokens are incentive systems with stronger guarantees

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

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

Those systems usually depend on application code.

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

That works, but the rules live in your system.

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

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

A mint defines the token

The first token in Arc 5 was deliberately simple.

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

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

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

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

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

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

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

That is the first Solana token model to carry forward:

Mint account: what the token is.

Token account: who holds how much of it.

Once that clicks, token balances stop feeling like magic.

Token-2022 makes the token itself more expressive

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

That distinction matters.

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

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

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

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

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

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

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

Associated Token Accounts are the default balance bucket

Arc 5 also introduced Associated Token Accounts, or ATAs.

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

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

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

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

balance = getBalance(userId, tokenId)

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

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

How much of this token does this wallet hold?

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

Transfer fees move marketplace logic into the token program

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

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

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

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

That is the important part:

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

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

There was also a very real developer gotcha: decimals.

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

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

Non-transferable tokens are useful because they fail

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

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

That failure was the point.

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

That makes sense for things like:

• verified badges

• course-completion certificates

• membership credentials

• KYC or compliance status

• reputation markers

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

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

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

But it can still be burned.

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

The lifecycle is the skill

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

create → configure → mint → transfer → collect

That pattern showed up again and again.

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

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

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

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

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

Building in public is part of the work

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

But this week had more to show.

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

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

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

That is good developer storytelling because it gives people proof.

Not "I learned tokens."

More like:

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

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

What Arc 5 sets up

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

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

That is the real shift.

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

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

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

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

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