Token Supply on Solana: Fixed, Deflationary, or Mintable

The supply you set on a Solana token at mint time is the single decision that follows your project the longest. You can rebrand. You can migrate liquidity. You can re-record metadata. But the supply story, who can print more, whether tokens leave circulation, and how decimals interact with price, is baked into the mint account the moment the transaction lands.

Most failed token launches I see on Solscan share one of three errors. The supply was set too high to make any per-token price meaningful. The mint authority was kept live after launch, so holders never trusted the float. The "deflationary" mechanic was a Discord promise with no on-chain enforcement. Each of these is a supply-strategy mistake disguised as something else.

This guide walks through the three real supply designs on Solana, fixed, deflationary, and mintable, with the trade-offs you only learn the hard way.

Why supply strategy matters before you mint

SPL tokens on Solana store supply as a 64-bit unsigned integer at the mint account, scaled by the decimals field. A token with 9 decimals and a supply of 1,000,000,000 actually holds 1_000_000_000 * 10^9 base units on-chain. This matters because two design decisions, the headline supply number and the decimals, together determine the smallest tradeable unit and the price granularity an AMM can quote.

Once the mint is initialized, you cannot change decimals. You also cannot retroactively cap supply unless you revoke the mint authority. Every other supply behaviour, deflation, rebasing, taxed transfers, has to be designed in before launch or simulated off-chain (which buyers will not trust).

Revoking the mint authority is a one-way action. Once the authority is set to null, no one, including you, can mint a single additional unit. Test on devnet first.

Fixed supply, the Bitcoin model

A fixed-supply token has a known cap and no live mint authority. The supply you minted at launch is the supply that will ever exist. This is the cleanest story to tell holders and the easiest for explorers and aggregators to verify.

USDC on Solana is technically mintable (Circle controls the authority and prints against off-chain dollar reserves), but most memecoins and community tokens choose the fixed model: mint the full supply once, send liquidity to a DEX, then revoke the mint authority in a separate transaction so anyone can verify the cap on Solscan.

Choose fixed supply when:

• The narrative is scarcity (memecoin, collectible, fan token).
• You want zero ongoing governance overhead.
• You will publish a transparent distribution plan and want it provable on-chain.

The trap: a lot of teams mint a fixed supply, list on a DEX, and forget to revoke the mint authority for weeks. During that window, buyers see a "mintable" badge on Solscan and rotate out. Revoke immediately 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 authority. If the token already exists, the mint authority revoke tool flips authority to null in a single form. The Make Immutable flag does the same for metadata, which matters if you want the symbol and image to be permanent.

Deflationary supply, burns and transfer fees

A deflationary token shrinks over time. Two mechanisms exist on Solana and they are not the same thing.

Manual or app-level burns. The classic SPL approach: a program, a treasury, or a community vote burns tokens by sending them to a burn instruction (the SPL token program's Burn ix permanently removes units from circulation and decrements the mint supply). BONK has done large community burns this way, and the burns are visible on-chain because each burn produces a transaction with a clear amount. The supply on Solscan drops permanently. For a treasury wallet doing it manually, the Solana token burn tool builds the burn instruction in a single form.

Token-2022 transfer fees. The newer Token-2022 program supports a transfer fee extension: a percentage (in basis points) of every transfer is withheld and accrues to a fee recipient. If the recipient burns the collected fees regularly, you get automatic deflation per trade, no DAO vote required. The recipient could also be a treasury that recycles the fees into buybacks. The Token-2022 creator tool lets you configure this extension at launch.

// Token-2022 transfer fee shape (j.tools Token2022 Creator)
extensions: {
  transferFee: {
    feeBasisPoints: 100,   // 1% of every transfer
    maxFee: 1_000_000_000, // cap in base units
    recipient: "Fee...wallet",
  }
}

Choose deflationary when:

• You want a built-in 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 recipient: burn, buyback, or treasury distribution with a published schedule.

Token-2022 fees apply to every transfer, including LP deposits and withdrawals on AMMs that support the extension. Verify your target DEX before launch. Raydium standard pools do not support Token-2022 extensions; CLMM and CPMM pool variants have different compatibility, and some aggregators 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 25 bps to 100 bps fee, paired with a public burn schedule, lands more credibly than a 500 bps fee that looks like an exit tax.

Mintable supply, when keeping the authority makes sense

A mintable token keeps the mint authority live, owned by a wallet, a multisig, or a program. New supply can be created at any time. This is the design every stablecoin and most governance tokens use.

USDC, USDT, and PYUSD on Solana are all mintable. Each issuer mints 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 a live mint authority routed through a program.

Choose mintable when:

• The token represents a redeemable claim on something off-chain (stablecoin, wrapped asset, RWA).
• You need staking emissions or programmatic rewards.
• Governance will vote on monetary policy.

The security implication is direct: whoever controls the mint authority can dilute every holder to zero. A single hot wallet holding mint authority is an insurance claim waiting to happen. The minimum standard is a Squads multisig with 3-of-5 or higher; the better standard is a program-controlled authority where the rules of minting are encoded in code that holders can audit.

If you keep mint authority alive, publish the wallet address or program ID on your project page. Buyers who can verify a multisig 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 immediately.
Gaming / utility token with volume	Deflationary (Token-2022 fee + burn)	Fees turn usage into scarcity.
Stablecoin / wrapped asset	Mintable (multisig or program)	Supply tracks off-chain reserves.
Governance token with staking	Mintable (program-controlled)	Emissions need a live authority.
Loyalty / points token	Mintable (issuer wallet)	Issuer mints on user action.

Practical execution on Solana

Before you sign the create-mint transaction, three numbers and three flags decide your token's future.

Decimals. Pick 6 for stablecoin-like tokens, 9 for most utility tokens (matches SOL), 5 or 6 for memecoins with very high headline supply (BONK uses 5). Decimals affect how small a unit can be priced; an aggressive memecoin with 9 decimals and a trillion supply prices each base unit at a value that is meaningless for any sane chart.

Supply. The SPL token program accepts any 64-bit integer, j.tools' token creator caps the input at 1 trillion for sanity. A "round" supply (1B, 10B, 100B) communicates intent. A weird supply (847,392,141) communicates that you do not know what you are doing.

Authority flags. The j.tools token creator exposes three:

• revokeMintAuthority: bakes the cap in. Required for a real fixed-supply token.
• revokeFreezeAuthority: removes the ability to freeze any holder's account. Required for any token that wants to look "DeFi-safe" to listings and aggregators.
• makeImmutable: locks the metadata (name, symbol, image). Required if you want listings to trust your branding.

The order matters: mint your full supply, send the bulk to liquidity and treasury, then revoke. If you revoke first, you cannot fund the LP from the mint authority anymore. Common mistake, hard to recover from.

Pre-liquidity checklist:

• Decimals locked in (cannot be changed).
• Total supply minted and distributed (LP, treasury, team vesting, community).
• Mint authority revoked (or visibly multisig'd if you need it live).
• Freeze authority revoked (almost always).
• Metadata immutable (if your brand is final).
• The mint 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. Mint on devnet, verify the on-chain state matches your plan, then ship to mainnet with the authorities your strategy actually requires.