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.
Bugün Xiaomi tarafından yapılan açıklamaya göre Xiaomi 17T serisi resmi olarak Türkiye’de de satışa sunulacak. 28 Mayıs’ta tanıtılacak ve aynı gün Türkiye’de ön satışa çıkarılacak seride, tam olarak iki farklı model yer alıyor. Kısa süre önce Roland Quandt tarafından detaylandırılan Xiaomi 17T, 6,59 inç boyutunda 120 Hz AMOLED ekran, MediaTek Dimensity 8500 Ultra işlemci, 12 GB LPDDR5X RAM, 256/512 GB UFS 4.1 depolama, 67W şarj destekli 6.500 mAh batarya ve 32 megapiksel selfie kamerasıyla geliyor. Cihazın arkasında ise 50 megapiksellik Light Fusion 800 sensörlü geniş açı, 5x optik zoom sunan 50 megapiksel telefoto ve 12 megapiksel ultra geniş açı kameralar bir araya getiriliyor. Üst model Xiaomi 17T Pro ise sızıntıya göre 6,83 inç boyutunda 144 Hz AMOLED ekran, MediaTek Dimensity 9500 işlemci, 12 GB LPDDR5X RAM, 512 GB UFS 4.1 depolama, 100W şarj destekli 7.000 mAh batarya ve 32 megapiksel selfie kamerasıyla geliyor. Cihazın arkasında 50 megapiksellik Light Fusion 950 […]
