Coming from a Web2 background, I originally thought about tokens in a very simple way. A token was something you create, mint, and transfer, while anything more interesting, like fees, restrictions, or identity, would probably live in the backend. Working through Solana token exercises changed that assumption for me.
Over the past few days, I built several kinds of tokens on Solana devnet: a basic token, a token with metadata, a token with transfer fees, a token that combined metadata and transfer fees, and finally a non-transferable token. What stood out most was not just that Solana lets you issue tokens, but that it lets you encode rules directly into the token itself through Token-2022 extensions.
A mint is not the same as a balance
One of the first ideas that became clearer to me was that creating a token is not the same thing as holding one. A mint defines the token, while a token account holds the balance of that token for a specific wallet. That separation felt unfamiliar at first, but after repeating the workflow a few times, it started to feel much more structured than my original mental model.
A basic flow looked like this:
