On Day 31 of MLH's 100DaysofSolana, I built a Token-2022 mint with a transfer fee extension. The instructions included one sentence that I didn't think much about at the time:
"Extensions must be configured when the mint is first created; you cannot add them later."
At the time, I treated it like any other instruction in a tutorial. I assumed it was simply one of those framework-specific rules you follow without asking too many questions. So I created the mint, completed the challenge, and moved on.
But over the next few days, as I created more Token-2022 mints with different extensions, I realized this wasn't just a one-off requirement for transfer fees. Every extension had to be decided before the mint existed. If I can deploy new features to a web application later, or add a new column to a database, why can't I create a token today with transfer fees and decide next week that I also want it to earn interest?
As it turns out, the answer has less to do with Token-2022 itself and more to do with how Solana stores data.
But before I go on, a quick detour if you are new to the world of tokens and Token-2022
Tokens
A token represents a digital asset on the blockchain. It could be a stablecoin, a governance token, a loyalty point, or even an NFT. But regardless of what it represents, every token begins with a mint.
You can think of a mint as the blueprint for that token. It defines core properties such as the token's supply, decimal precision, mint authority, and the rules that govern how new tokens are issued.
Token-2022 Extensions
The original Solana Token Program provides the basic functionality most tokens need: creating tokens, minting new ones, transferring them between accounts, and burning them. But many real-world applications require additional behavior. A stablecoin might charge a transfer fee. A rewards token might earn interest over time. An NFT collection might store metadata directly on-chain.
Instead of creating a new token program for every one of these use cases, Token-2022 introduces extensions (optional features) that add new capabilities to a token mint. You choose only the extensions your application needs, whether that's transfer fees, interest-bearing balances, metadata pointers, permanent delegates, or something else.
Now that that's cleared, let's circle back to the question:
If they're just optional features... why can't I enable one later?
If you've ever enabled authentication, payments, or file uploads in a web application, you've already worked with the idea of adding capabilities to a system over time. That's why Solana's requirement to choose certain token capabilities before the token even exists feels so unusual.
The Missing Piece
As I continued through the challenge, I created different Token-2022 mints with different extensions. Then, on Day 39, instead of creating another token, we inspected the ones we'd already built by running the token display command:
spl-token display $MINT --program-2022
SPL Token Mint
---
Extensions
------------
Transfer Fee
Metadata Pointer
Metadata
I repeated this for three different tokens and compared their account sizes and rent costs.
| Mint address | Extensions enabled | Account data size (bytes) | Rent cost (SOL) | Key authorities |
|---|---|---|---|---|
Ay6J...qTwGkDp |
Interest-bearing | 222 | 0.002436 | Mint authority:EHAj6...XQgjFreeze authority: None Rate authority: EHAj6...XQgj
|
5CyH...vwwSx |
Interest-bearing Transfer fees Metadata Pointer Metadata |
599 | 0.00505992 | Mint authority:EHAj6...XQgjFreeze authority: None Rate authority: EHAj6...XQgjTransfer fee config authority: EHAj6...XQgjTransfer fee withdrawal authority: EHAj6...XQgj
|
Cc1E...XvmH |
Default Account State (Frozen) | 171 | 0.00208104 | Mint authority:EHAj6...XQgjFreeze authority: EHAj6...XQgj
|
One thing immediately stood out, the more extensions a mint had, the larger the account became.
Why Extensions Must Be Added at Creation
The answer lies in how Solana stores data. On Solana, everything is stored in accounts. Unlike a typical database where storage can grow as you add more data, Solana accounts are created with a fixed amount of space. Once an account is initialized, that allocated space doesn't automatically expand.
That means when you create a Token-2022 mint, Solana isn't just creating a token, it is allocating enough storage to hold everything that mint will ever need. Every extension you enable becomes part of that mint account, it isn't just a switch that turns a feature on or off. It stores its own configuration data inside the mint account.
For example, a transfer fee extension needs to keep track of information such as the fee basis points, the maximum fee, and the authorities responsible for updating or withdrawing fees. A metadata extension stores information about where the token's metadata lives. Since each extension carries its own data, every additional capability increases the amount of storage the mint account requires and Solana needs to know exactly how much space to allocate before the mint exists. The process looks something like this:
Choose the extensions your token needs
│
▼
Calculate the total account size
│
▼
Allocate storage for the mint account
│
▼
Calculate the rent-exempt balance
│
▼
Create the mint
Now, that instruction from Day 31 stopped sounding like a rule I had to memorize, it became the natural consequence of Solana's account model. I now know that I can't add an extension later because there isn't extra space waiting to be used. Adding another extension later would require the mint account to grow, and Solana accounts don't grow like rows in a relational database.
Coming from Web2, I was used to thinking of software as something that evolves over time. If I needed another feature, I'd update the schema or deploy another version of the application. Token-2022 challenged that mental model. On Solana, you're not just defining what your token does today; you're deciding how much space it will ever need before it's even created. A short comparison like this helps to put it more into perspective.
| Web2 | Solana |
|---|---|
| Add a database column later | Allocate account space up front |
| Deploy new application features | Decide mint capabilities before creation |
| Storage grows as needed | Storage is fixed at account creation |
Conclusion
Looking back, that sentence from Day 31 wasn’t just a rule to follow, it was a constraint that revealed how Token-2022 is designed. At first, it felt like an arbitrary limitation: why force developers to decide everything up front? But after working through multiple mints and eventually inspecting them on-chain, the reason became clear.
Token-2022 isn’t designed around “features you can turn on later.” It’s designed around state that must be fully allocated before it exists. Every extension becomes part of the mint’s storage footprint from the very beginning, which is why the system forces you to define its shape at creation time.
What changed for me wasn’t just my understanding of Token-2022, it was how I think about building on Solana. On Solana, you don’t evolve accounts over time; you design them before they exist. That’s a very different way of thinking compared to Web2, and one of the most valuable lessons I took away from Epoch 2 of 100 Days of Solana.
If you've had a similar "Why does Solana work this way?" moment while learning, I'd love to hear about it in the comments.
Top comments (0)