Token Supply on Solana: Fixed, Deflationary, or Mintable
Fixed, deflationary, or mintable: the supply design you pick at mint time follows your Solana token forever. A practical guide with real examples.
The supply you set on a Solana token at launch is the single decision that follows your project the longest. You can rebrand later. You can move liquidity to a different pool. You can update the name. But the supply story, meaning who can produce new tokens, how tokens leave circulation, and how price gets sliced into small enough pieces to chart, gets written into the chain the moment your first transaction lands.
Most failed token launches on Solscan share one of three mistakes. The supply was set so high that the per-token price never meant anything. The team kept the "create new tokens" permission live after launch, so buyers never trusted the float. The "deflationary" mechanic was a Discord promise with nothing enforcing it on-chain. Each of these is a supply-strategy mistake wearing a different costume.
This guide walks through the three supply designs people actually use on Solana: fixed, deflationary, and reprintable. Each one comes with its own trade-offs, and you only learn most of them the hard way.
Why supply strategy matters before you launch
The supply of a Solana token lives in one slot on-chain, scaled by a decimals setting. A token with one billion supply and nine decimals actually carries a billion times a billion tiny "cents" in the chain's internal counter. This detail matters because two choices, the headline supply number and the decimal depth, together decide the smallest unit an exchange can trade and the price resolution the chart can show.
Once the token is created, you cannot change the decimals. You also cannot retroactively cap the supply unless you completely give up the "create new tokens" permission. Every other supply behaviour (deflation, transfer fees, programmed rewards) has to be designed before launch. Add it later and buyers will not trust the part that is still loose.
Giving up the "create new tokens" permission is a one-way decision. Once you switch it off, no one, including you, can produce a single additional unit. Test it on devnet first.
Fixed supply, the Bitcoin model
A fixed-supply token has a known cap and no live "create new tokens" permission. The amount you minted at launch is the amount that will ever exist. Think of it as a limited-edition print run: the printer plates get destroyed after the last copy, and nobody can run the same series again. This is the cleanest story to tell holders and the easiest one for listing sites to verify.
Bitcoin's 21 million cap is the classic version of this. On Solana, most memecoins and community tokens pick the same model: print the full supply once, send liquidity to a DEX, then revoke the "create new tokens" permission in a separate transaction so anyone can verify the cap on Solscan. (USDC on Solana is technically reprintable; Circle keeps the permission and prints against off-chain dollar reserves. So fixed supply is the right choice for tokens with a scarcity story, not for stablecoins.)
Choose fixed supply when:
- Your narrative is scarcity (memecoin, collectible, fan token).
- You want zero ongoing governance overhead.
- You plan to publish a transparent distribution and want it provable on-chain.
The trap: a lot of teams mint the fixed supply, list on a DEX, and then forget to revoke the "create new tokens" permission for weeks. During that window, Solscan shows a "still reprintable" badge and buyers rotate out. Revoke right after the initial mint completes.
On the practical side, the Solana token creator tool bundles the "Revoke Mint Authority" flag into the create transaction itself, so the token ships to mainnet with no live permission. If the token already exists, the mint authority revoke tool flips the permission off in a single form. The make immutable tool does the same for the token's visible identity, which matters if you want the symbol and image to be permanent.
Deflationary supply, burns and transfer fees
A deflationary token shrinks over time. Every transaction shreds a tiny piece, and the total stock only moves in one direction. Two mechanisms do this on Solana and they are not interchangeable.
Manual or app-driven burns. The classic approach: a wallet, a program, or a community vote permanently deletes a chunk of supply. BONK has done large community burns this way. Each burn produces a transaction with a clear amount, so it is easy to verify on-chain, and the total supply on Solscan drops permanently. For a treasury wallet doing it directly, the Solana token burn tool builds the burn in a single form.
Transfer fees on Token-2022. Solana's upgraded token system supports a transfer-fee feature: a small percentage of every move (typically between 0.5% and 1%) gets withheld and routed to a pre-set wallet. If that wallet burns the collected fees on a schedule, every trade automatically produces deflation, no vote required. The same wallet could also be a buyback treasury. The Token-2022 creator tool lets you configure this at launch.
In practice, a 1% transfer fee paired with a public weekly burn schedule produces a believable engine: as volume rises, the supply visibly shrinks. Keep the fee too high and the engine stalls; keep it modest but publish a real schedule and the story holds.
Choose deflationary when:
- You want a working scarcity narrative beyond a fixed cap.
- The token has real transfer volume (a fee on no volume burns nothing).
- You have a credible plan for the fee wallet: burn, buyback, or treasury distribution, with a public schedule.
Token-2022 fees apply to every transfer, including liquidity adds and removals. Verify your target DEX before launch. Raydium's standard pools do not support Token-2022 features; some routing services silently skip incompatible tokens.
The trap: high transfer fees (3% and above) kill volume. Bots and arbitrage stop, real users avoid the token, and the deflation engine starves. A fee between 0.25% and 1%, paired with a public burn schedule, lands far more credibly than a 5% fee that reads like an exit tax.
Reprintable supply, when keeping the permission makes sense
A reprintable token keeps the "create new tokens" permission live, owned by a wallet, a multi-signature vault, or a program. The team keeps the printer in the basement and can print more whenever the rules say so. Every stablecoin and most governance tokens use this design.
USDC, USDT, and PYUSD on Solana are all reprintable. Each issuer prints new tokens when fiat enters the reserve and burns tokens when fiat leaves. The supply expands and contracts with real-world demand. JTO (Jito's governance token) launched with a fixed initial distribution, but the long-term plan involves emissions controlled by governance, which requires keeping the permission live and routing it through a program.
Choose reprintable when:
- The token represents a redeemable claim on something off-chain (stablecoin, wrapped asset, real-world asset).
- You need staking rewards or programmed distributions.
- Governance will vote on monetary policy.
The security implication is direct: whoever holds the "create new tokens" permission can dilute every holder to zero. A single hot wallet holding that permission is an insurance claim waiting to happen. The minimum standard is a Squads multi-signature vault that requires 3 of 5 signers to approve any mint; the better standard is a program-controlled permission where the rules of minting are written in code that holders can audit.
If you keep the permission live, publish the wallet address or program ID on your project page. Buyers who can verify a multi-signature vault sleep better than buyers who hear "trust us, it's safe".
Picking the right model
A quick decision frame:
| Project type | Best fit | Why |
|---|---|---|
| Memecoin / community token | Fixed | Scarcity is the entire pitch. Revoke mint and freeze right away. |
| Gaming or utility token with real volume | Deflationary (Token-2022 fee + burn) | Fees convert usage into scarcity. |
| Stablecoin / wrapped asset | Reprintable (multi-sig or program) | Supply tracks off-chain reserves. |
| Governance token with staking | Reprintable (program-controlled) | Emissions need a live permission. |
| Loyalty or points token | Reprintable (issuer wallet) | The issuer prints on user action. |
Practical execution on Solana
Before you sign the create transaction, three numbers and three flags decide your token's future.
Decimals. Pick 6 for stablecoin-style tokens, 9 for most utility tokens (matches SOL), 5 or 6 for memecoins with very high headline supply (BONK uses 5). Decimals decide how small a unit can be priced. An aggressive memecoin with 9 decimals and a trillion supply will price each smallest unit at a number too tiny for any reasonable chart.
Total supply. The j.tools token creator caps the input at one trillion for sanity. A round supply (1B, 10B, 100B) reads as intentional. A weird number (847,392,141) reads as someone who does not know what they are doing.
Permission flags. The j.tools token creator exposes three:
- Revoke mint permission: bakes in the cap. Required for a real fixed-supply token.
- Revoke freeze permission: removes the team's ability to freeze any holder's account. Required for any token that wants to look "DeFi-safe" to listings and routing services.
- Make immutable: locks the name, symbol, and image. Required if you want listings to trust your brand.
The order matters. Mint your full supply, send the bulk to liquidity and treasury, then revoke. If you revoke first, you cannot fund the liquidity pool from the mint permission anymore. Common mistake, hard to recover from.
If you ever need a frozen snapshot of who holds what after distribution, the token holder snapshot tool downloads the list at a specific block height. That gives you a clean starting point for an airdrop, a vesting audit, or a retroactive reward.
Pre-liquidity checklist:
- Decimals locked in (cannot be changed).
- Total supply minted and distributed (liquidity, treasury, team vesting, community).
- Mint permission revoked (or visibly multi-sig'd if you need it live).
- Freeze permission revoked (almost always).
- Identity made immutable (if your brand is final).
- The token address shared publicly so buyers can verify on Solscan before the first trade.
For more launch-prep walkthroughs, see the Solana guides category, and for related token mechanics dig into all Solana tagged posts.
The boring read is the right one. Supply strategy is a 10 minute conversation that decides whether your token reads as serious in its first hour of trading. Launch first on devnet, verify the on-chain state matches your plan, then ship to mainnet with the permissions your strategy actually needs.
