Burn Solana Tokens vs Revoke Mint Authority
Burn vs revoke mint on Solana, explained as orthogonal operations with a 2x2 matrix. When to burn, when to revoke, when to do both, mistakes to avoid.
"I'm going to burn the rest of the supply." Half the time, the operator saying this actually means "I'll revoke mint authority." Sometimes they mean both. They are not the same operation, and the difference shows up the second a holder opens Solscan.
Burning tokens and revoking mint authority are independent. They affect different parts of your token, and each combination tells buyers a different story.
The two operations in plain words
Burning tokens. A burn destroys tokens that exist right now. Whoever holds them (treasury, dev wallet, community vault) sends them to a burn instruction, and the on-chain total supply drops. The "mintable" badge on Solscan stays the same. The supply ceiling stays the same. Only the current circulating number gets smaller. Burn 100M out of a 1B mint and the chain reads 900M total, but the authority to print new ones is untouched.
Revoking mint authority. Revoking does not destroy a single token. It removes the permission to ever print new ones. Current supply stays at whatever it is the moment you sign. Solscan flips the "mintable" badge to off. Buyers and listing teams treat this as the no-rug-via-inflation signal. If you minted 1B and never burned, the supply stays at exactly 1B until someone burns some, and even then only the burner's balance changes.
Burning moves the current supply line down. Revoking puts a ceiling on it. One is about now; the other locks the future.
Most common misconception: "I burned a chunk so no more can come." False. Burning does not lock supply. Until mint authority is also revoked, the project can mint replacement tokens the next block. Supply can drop and then re-inflate from the same wallet that just looked like a hero.
The 2x2 matrix
Four combinations, four different stories for a buyer:
| State | What buyers see | Real-world example |
|---|---|---|
| Mint LIVE, no burns | Standard mintable token. Solscan shows "mintable: yes". Trust depends on the team's word. Buyers price the risk in. | Day-zero memecoin before any cleanup. Most rug candidates sit here. |
| Mint LIVE, burns done | "Deflationary illusion." Supply dropped but the mintable badge is still on. The wallet that burned can mint replacements anytime. | A team runs a "20% community burn" for marketing but keeps mint authority. Holders cheer; the ceiling is unchanged. |
| Mint REVOKED, no burns | Hard-capped at current level. Supply cannot grow. Listing teams see "mintable: no" and breathe. Most clean launches end here. | Standard 1B memecoin: mint everything at launch, fund LP, revoke. Done. |
| Mint REVOKED, burns done | Fully locked AND reduced. Strongest on-chain deflation signal. Supply can only go down from here. Verifiable in 30 seconds. | An unsold-ICO burn followed by revoke. Or scheduled treasury burns after the cap was locked at launch. |
When you should burn
Burns are useful when you have a concrete reason for the supply to drop. Without a reason, a burn is just theater.
- Unsold ICO or presale supply. Allocated 200M, sold 130M, 70M sits with no plan. Burn it. The cap drops to what holders actually paid for.
- Treasury cleanup. Leftover tokens from a partnership that never shipped, an LP migration, or a closed program. Burning is cleaner than parking them.
- Post-airdrop dust. Some airdrop wallets never claim. Sweep the unclaimed portion so the dust does not haunt your circulating-supply math.
- Marketing burn with a story. Scheduled community burns work if the source is auditable and the cadence is announced upfront. Random spike burns to pump a chart age badly.
- Deflationary mechanic. Programmatic burns tied to fee revenue, buybacks, or supply governance. These need design, not vibes.
For any of these, the Solana token burn tool handles one-time or repeatable burns from a source wallet.
When you should revoke mint
Revoke is a trust gate; the deflation lever lives elsewhere. You revoke when the supply is final.
- Pre-listing on a DEX or aggregator. Jupiter, Raydium UI, and most listing pages surface the mintable badge prominently. Revoke before you ask for visibility.
- Before adding meaningful liquidity. Once you commit real SOL or USDC into an LP, you are putting capital behind a token whose cap is still open. Lock the cap first.
- After distribution is final. Team, treasury, airdrop, marketing, LP supply; all minted and parked. Then revoke.
- For any memecoin launch. Holders expect this on day one. A live mint authority on a fresh memecoin reads as "still wants printer access."
The revoke mint authority tool is the one-tap path. Sign once, the authority is gone forever.
Doing both is the "we mean it" signal
The strongest launch posture combines them in order:
- Mint the full intended supply in the launch transaction. Team, treasury, LP, airdrop, all of it.
- Distribute to the wallets that will hold the supply. LP funded, vesting contracts seeded, airdrop snapshot ready.
- Revoke mint authority. Cap is now locked.
- Burn over time from the treasury or programmatic flows if your tokenomics call for it.
This sequence gives buyers the cleanest read. Cap locked, subsequent burns only push supply lower. While you are at it, the revoke freeze authority tool and the make metadata immutable tool close the other two switches most listing teams check. For deeper context on all three authorities, see the revoke authority guide.
j.tools step-by-step
Both operations share the same shape: connect wallet, paste mint address, sign.
Burn. Connect the wallet that holds the tokens you want to destroy, paste the mint address, enter the amount, sign. Confirm on Solscan that the total supply dropped by what you burned.
Revoke mint. Connect the wallet that currently holds the mint authority (usually the deployer), paste the mint, sign. After the transaction lands, refresh Solscan and check that the mint authority field reads null and the mintable badge is off. No undo. Read the warning callout above twice before clicking.
Common mistakes
- Burning treasury and thinking the cap is locked. The mintable badge stays on. The team can mint a fresh batch the next block. If your goal was "no more inflation," you wanted revoke.
- Revoking mint before the team allocation is sent. If your distribution wallet has not received its share yet and you revoke, the rest of the planned supply is permanently lost. Mint everything first, distribute, then revoke.
- Burning from the LP-paired pool wallet. Burning tokens already inside a Raydium or Meteora LP destroys pool depth. Slippage explodes. Always burn from a non-LP wallet.
- Revoking too early on a fresh launch. If you revoke before the metadata is final, you cannot fix typos in name or symbol. Lock the cap last, after the artwork and copy are signed off.
For which burns actually move a chart versus which are theater, the token burn strategy guide goes a layer deeper.
The short version
Burn changes supply now. Revoke locks the ceiling forever. They solve different problems, and the right move for almost any clean launch is both, in order: distribute, revoke, then burn over time if your tokenomics asks for it. Spin up a devnet token via the SPL token creator tool first if you have not done this before. Practice runs cost nothing; a wrong revoke on mainnet costs everything.
More launch playbooks live under the guides category and the Solana tag.
