Burn Coin: When Burning Builds Trust (and When It's Theater)

"Burn the coin" is three different on-chain mutations dressed up as one slogan. You can call the SPL Token Program's Burn instruction against the supply, you can call the same instruction against an LP token mint, or you can call SetAuthority and set the mint authority to None. Each one means something different to traders, gets verified differently on Solscan, and is right or wrong for different reasons. Treating them as interchangeable is how founders end up announcing a "100% burn" that an experienced trader looks at for five seconds, calls theater, and walks away from. After 47 launches I'm willing to argue that burning is overprescribed: useful in two cases, misleading in three more.

The word "burn" is doing three jobs

When someone on Crypto Twitter says "I burned the coin," they could mean any of three on-chain actions, and the three have almost nothing in common except the verb.

Burning supply. The deployer holds tokens in a wallet, calls the SPL Token Program's Burn instruction (program ID TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA), and the tokens are deducted from the wallet's balance and from the global supply on the mint account. The cost is roughly 0.000005 SOL of compute. The action is reversible only in the sense that the deployer can mint more, if the mint authority is still active. This is what most beginners mean by "burn."

Burning LP tokens. When you create a Raydium pool, you receive LP tokens that represent your share of the pool. Calling Burn against the LP token mint sends them to oblivion. The pool keeps trading. The liquidity stays locked because no one (not even you) can redeem the underlying SOL + token without the LP receipt. This is the strongest trust signal on Solana right now, and it's covered in detail in how to burn LP tokens on Solana.

Revoking mint authority. This is SetAuthority(authorityType: MintTokens, newAuthority: None). It's a different instruction from Burn entirely. The supply doesn't change. What changes is that no one can ever call MintTo again. The mint authority is permanently null. By Solana's protocol design, this is irreversible. There's no admin override, no governance recovery, no Plan B. Detail and walkthrough in how to revoke mint authority on Solana.

You can also send tokens to a known unreachable address, like the incinerator wallet 1nc1nerator11111111111111111111111111111111, which some early Solana communities used as a quasi-burn. It's not a Burn instruction (the supply on the mint doesn't drop), but it removes the tokens from circulation in practice. Honest, but rarely what people mean.

Here is the conflation in one line, the way I see it in client onboarding calls weekly: founder says "I want to burn the coin to prove I won't rug." The literal interpretation is "burn supply." The actual right answer is almost always "revoke mint authority and, if you have LP, burn the LP tokens." Two different on-chain actions, neither of which is what they asked for.

flowchart TD
  A["I want to prove I won't rug"] --> B{What am I trying to lock?}
  B -->|"Future supply (no more printing)"| C[SetAuthority MintTokens to None]
  B -->|"Pool liquidity (can't pull out)"| D[Burn against LP token mint]
  B -->|"My personal float (token-economic gesture)"| E[Burn against the supply]
  C --> F[Irreversible by protocol design]
  D --> G[Pool keeps trading, liquidity locked]
  E --> H["Marketing gesture, doesn't lock anything"]

The diagram above is the difference between the three. The fact that all three are called "burning" in casual writing is a vocabulary problem, not a token-economics one.

What each burn type actually proves (and doesn't)

The framework below is what I walk every paid client through before they sign anything. It maps the operator's actual goal onto the on-chain instruction that achieves it, plus the protocol-level note about whether the action is reversible.

GOAL                              ACTION                     ON-CHAIN INSTRUCTION
─────────────────────────────────────────────────────────────────────────────
Reduce circulating float          Burn supply                Burn / BurnChecked
Lock liquidity forever            Burn LP tokens             Burn (on LP mint)
Cap supply at current value       Revoke mint authority      SetAuthority(None)

Read each row as: if your goal is X, you sign Y, which calls Z. The mapping is exclusive. You can't substitute one for another. Burning supply does not cap supply (if the mint authority is alive, you can print more tomorrow). Revoking mint authority does not lock liquidity (the LP tokens still sit in your wallet, redeemable). Burning LP tokens does not reduce circulating float (your supply on the mint stays unchanged).

The trust implications follow from the protocol mechanics, not from the announcement copy.

Burn type	What it proves to a trader	Verifiable on Solscan	Reversible?
Burn supply	"Deployer sent X tokens to oblivion"	Yes, Burn instruction in tx history	Re-mintable if mint authority is still active
Burn LP tokens	"Deployer cannot pull pool liquidity"	Yes, LP mint shows reduced supply or zero	No, by protocol (LP receipt is destroyed)
Revoke mint authority	"Supply is capped at current circulating amount"	Yes, Mint Authority field on mint account reads None	No, by protocol (SetAuthority(None) is one-way)

Look at the third column. Two of the three are protocol-level irreversible. One is just an accounting move that can be undone the next block.

The numbers behind each action

The on-chain cost asymmetry is the part that gets missed. Below is the per-instruction cost in lamports + compute units, what that translates to in SOL at typical mainnet conditions, and the USD equivalent at SOL = $200 (a sober reference point — SOL traded $135 to $264 across 2025-2026 Q1).

Instruction	Lamports per signature	Compute units (CU)	SOL cost	USD @ $200	Reversible?
Burn (supply)	5,000	~4,200 CU	0.000005 SOL	$0.001	Yes if mint authority still active
Burn (LP token)	5,000	~4,200 CU	0.000005 SOL	$0.001	No — protocol level
SetAuthority(MintTokens, None)	5,000	~3,100 CU	0.000005 SOL	$0.001	No — protocol level
SetAuthority(FreezeAccount, None)	5,000	~3,100 CU	0.000005 SOL	$0.001	No — protocol level
Combined revoke + LP burn (alchemii single-sig)	5,000	~14,000 CU	0.000005 SOL	$0.001	No — one tx, two irreversibles
Send to incinerator address (transfer)	5,000	~2,800 CU	0.000005 SOL	$0.001	No, but supply field unchanged

Three observations from that table that matter for decisions:

1. All five protocol actions cost the same 5,000 lamports of base fee because the Solana base fee is fixed per signature, not per instruction. Compute units differ but compute units only cost SOL above the 200,000 CU per-instruction baseline. None of these actions touch that ceiling.
2. Two Burn calls cost exactly the same (5,000 lamports each) but one is reversible and one isn't — the "is it reversible" question lives in which mint you burned against, not in the cost or instruction name.
3. A combined revoke + LP burn fits in a single Solana transaction because each instruction stays well under the 200,000 CU budget. That's why alchemii's flow signs once; it's not a UX shortcut, it's a Solana protocol affordance.

For the LP-burn cost in particular: Raydium V4's LP token mint follows standard SPL rules, so a burn against an LP mint with 10,000 LP tokens costs the same 0.000005 SOL as a burn against an LP mint with 10,000,000 LP tokens. The cost is per-call, not per-token. I have clients who held back on burning LP because they assumed "more LP = more cost." The cost doesn't scale with the amount being burned.

The cost asymmetry is what makes burn announcements such an information-poor signal in isolation. A founder spent 0.000005 SOL on the announcement; verifying it takes the reader 90 seconds. That's why the 3-Burn Decision Framework maps to protocol mechanics rather than to announcement intent — the announcement and the action are pricing different things.

This is where most "we burned the coin" announcements fall over. The trader pulls up the Solana Explorer page for the mint, checks the Mint Authority field, and sees a live address. Burning the float without revoking mint authority is the "I locked the front door but left the printing press running in the basement" of token launches. It's a gesture, not a guarantee.

The reference point: USDC at EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v does not burn its float; it relies on Circle's reputation. BONK at DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263 (100T supply, 5 decimals) burned a significant fraction of its initial float and revoked authorities. Pull both up on Solscan and the difference in trust models is visible in 30 seconds. Float burns are a marketing artifact. Authority revokes are the structural commitment.

For the LP side, the same logic holds. A pool with the LP tokens sitting in the deployer's wallet is one signature away from a rug. If you're creating a Raydium pool from scratch, the LP burn uses the same Burn instruction, pointed at a different mint. A pool whose LP mint shows a Burn instruction to zero is structurally rug-proof for that pool. The difference is not in the size of the burn. It's in which mint the burn happened against. There's a recurring confusion about this addressed in burned LP tokens still showing liquidity, which describes exactly the case where the LP burn succeeded but the pool's underlying liquidity is still visible (which is the intended outcome, not a bug).

If you remember nothing else from this section: the trust signal is the combination of which mint you burned against and which authority you revoked. Single-mint burns without authority revokes are theater. Authority revokes without LP burns leave the pool exposed. The matrix is small, but it's not one cell.

Burning is overprescribed: three cases where it actively hurts

Here is the contrarian half of the argument. Most tokens should not burn anything, and most tokens that announce a burn are signaling the wrong thing. Three cases where I'd actively recommend against a supply burn.

Case 1: Utility tokens that need inflation. If your token has any kind of real-economy purpose (rewards, staking yield, ecosystem grants), you need a live mint authority to handle future emissions. Burning the float here is a marketing wash that doesn't change the underlying tokenomics. Revoking mint authority would actively break the product. The right move: keep mint authority on a Squads multisig (so it's hard to abuse but not impossible to use), don't burn anything, and explain the inflation schedule in plain English. Founders who pre-burn 50% of their utility supply to look "serious" usually regret it within a year when the emissions math starts failing.

Case 2: Tokens where the trust signal traders actually check is the authority field, not the burn percent. Jupiter's strict-list (the gate that determines whether your token appears in the default aggregator UI) checks mint and freeze authority being null. It does not check the burn percentage. Most aggregators behave the same way. Phantom's token indexing pipeline (the 30-day window where new tokens move from "Unknown" to a recognized ticker) also keys on authority state. So if you burn 30% of the float but leave mint authority active, you've optimized for the audience that reads the announcement copy, not the audience that reads the on-chain state. The on-chain readers are the ones with capital.

Case 3: This is also the limitations honest-list. A few cases where this whole framework doesn't apply. Tokens that route through pump.fun's bonding curve don't have a separate LP burn step in the conventional sense, because the bonding curve is the AMM until graduation. Context in is pump.fun safe. Token-2022 launches (program ID TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) have additional authority surfaces (Transfer Hook, Permanent Delegate, etc.) that revoking three classic authorities doesn't cover. And vesting or staking contracts that hold large fractions of supply look like an unburned float on Solscan even when they're contractually locked. Burning to "prove" liquidity in those cases would be lying with on-chain data.

From spot-checks on Solscan (not a formal study), roughly half of recent "fully burned" claims I dug into had at least one of the three actions missing. Specifically: 5 of 10 tokens I randomly checked from the DexScreener Solana trending feed in the last two weeks claimed "100% burned" while still showing either an active mint authority, unburned LP tokens in the deployer wallet, or both. None of these are scams in the immediate-rug sense. They're closer to founders who read three "how to launch a memecoin" articles and conflated the vocabulary. The launches survive or die for other reasons, but the trust signal they thought they were sending isn't the one traders received.

The honest framing: burning is a tool. It's the right tool for two cases. One is locking pool liquidity. The other is the legitimate "we want to retire some float to tighten the float-to-FDV ratio" tokenomics decision. It's the wrong tool for "I want to prove I won't rug." That's what authority revocation is for, and the action is named differently for a reason. Useful background on the supporting concepts: what is mint authority on Solana and what is freeze authority on Solana.

The verifiability test: how to actually check a burn

If someone claims their token is "fully burned," here's the 4-step verification anyone with a browser can run. The whole sequence takes about 90 seconds.

Step 1. Pull the mint address into Solscan. Open solscan.io/token/<mint-address>. The page shows: total supply, decimals, mint authority, freeze authority, and the top holders. Bookmark this. Every claim in the announcement either resolves to a field on this page or it's hand-waving.

Step 2. Check the Mint Authority field. If it reads a real address, mint authority is live and supply can grow. If it reads null or the field is empty, mint authority has been revoked and the supply is capped at current circulating. This is the structural commitment. A burn announcement that leaves this field populated is a marketing gesture.

Step 3. Find the LP pool and check the LP mint. On the same Solscan page, scroll to the pool's address (usually visible on the token's market page, or via DexScreener). The LP token has its own mint account. If the LP mint's supply has been burned to zero (or close to it), the pool's liquidity is structurally locked. If LP tokens sit in the deployer's wallet, the pool is one signature away from a withdrawal.

Step 4. Cross-check with Solana Explorer on the mint authority field, separately. This catches the rare cases where Solscan's indexer is stale. Two independent indexers, same null Mint Authority, is a structural fact.

Check	Where to look	What "good" looks like
Mint authority	Solscan mint page → Mint Authority	null / empty
Freeze authority	Solscan mint page → Freeze Authority	null / empty
LP burned	LP token mint → supply	Zero or near-zero
Independent confirmation	Solana Explorer → same mint page	Matches Solscan

Five reference tokens, side-by-side

To calibrate what "good" and "live-and-trusted" actually look like, here are five Solana SPL tokens that pass or partially pass the verifiability test, with the exact field values a trader sees on Solscan today. All five mints are verifiable in 30 seconds each.

Token	Mint (truncated)	Total supply	Decimals	Mint auth	Freeze auth	LP mint burned?
BONK	DezX...PB263	100T (10^14 × 10^5)	5	null	null	Yes (Raydium V4 pool, LP burned 2023)
WIF	EKpQ...zcjm	1B (10^9 × 10^6)	6	null	null	Yes (Raydium V4)
POPCAT	7GCi...pump	979M	6	null	null	Yes (Raydium V4)
USDC	EPjF...TDt1v	dynamic (~5B)	6	Active (Circle)	Active (Circle)	N/A (issued, not pool-LP)
Mock "I burned 50%" launch	(theoretical)	1B	6	Active (deployer wallet)	Active (deployer wallet)	N/A (no Raydium pool)

The first three are the "actually burned" template: memecoin-standard 1B-100T supply, 5-6 decimals, both authorities null, and the LP burned against a real Raydium V4 pool. USDC is the opposite-end correct case: Circle keeps both authorities active because the token's job is centralized issuance + regulatory freeze of blocklisted wallets. That's the right tradeoff for USDC and a wrong tradeoff for a memecoin. The fifth row is the trap pattern: float-burned, authorities live, no LP burn. Solscan shows "deployer burned 500M of 1B supply" in the tx history while Mint Authority still points at a live wallet. That's theater, not commitment.

The 4-second mental check: scan the two Authority fields. If both are null, the supply is structurally capped. If either is a live address, supply is not capped, and any "100% burned" headline is misleading until both authorities go to null.

The reason I'm laying this out as a 4-step browser walk is that the asymmetry between the actions and the verification is enormous. A founder can sign a single Burn instruction for 0.000005 SOL in compute fees and write "100% burned" in their announcement. Verifying whether that burn actually achieved the trust outcome takes 90 seconds and four fields. We should normalize doing the verification before any wallet decision, the same way we'd normalize checking the address of a smart contract before approving spend on Ethereum.

For the broader pre-launch operational sequence (the order in which to mint, add LP, burn LP, and revoke authorities), see the Solana memecoin launch checklist. The reason the checklist puts authority revocation last is that you want to revoke only after you're certain the metadata and supply are exactly what you want. Update authority revocation in particular is one of the actions you cannot take back, and a typo in the ticker becomes part of the on-chain record forever.

If you've made it this far and you're still planning to "burn the coin to prove you won't rug," go re-read the framework. The action that produces the trust outcome you described is SetAuthority(MintTokens, None), not Burn(supply). The fact that we share a verb for both is a vocabulary accident. The structural difference matters more than the headline.

Cited work

• SPL Token Program reference: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA, the Burn and SetAuthority instructions, decimals and supply semantics.
• Solana docs: Programs and rent: account model and the cost of compute for individual instructions.
• Solana Program Library on GitHub: canonical source for the Token Program's instruction set, including Burn, BurnChecked, and SetAuthority.
• Token-2022 extension docs: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb, the additional authority surfaces (Transfer Hook, Permanent Delegate) that classic three-authority revokes don't cover.
• Metaplex Token Metadata docs: update authority semantics, the third authority that "revoking everything" needs to account for.
• Raydium docs: AMM V4 and CLMM: LP token mechanics, pool creation, and the burn pattern for proving liquidity is locked.
• Jupiter strict-list docs: the gate criteria for default-aggregator visibility, which check authority state but not burn percentage.
• Phantom Learn: token visibility: the ~30-day indexing window where new tokens move from Unknown to recognized in the wallet UI.
• Solscan: BONK token page: live state for BONK (100T supply, 5 decimals, mint authority revoked).
• Solscan: USDC on Solana: 6 decimals, the parity benchmark, mint authority still live (Circle issuance model).
• Solana Explorer: independent indexer for cross-checking mint authority state when Solscan is stale.
• DexScreener: Solana feed: pool discovery and the LP mint addresses used in Step 3 of the verification walk.

---

If you're about to launch and you actually want the trust outcome that most founders mean when they say "burn the coin," alchemii bundles authority revocation and LP burn into the same signed transaction as token creation. The framework above is the reason that bundle exists in that exact order: those are the two actions that produce the structural commitment, and they're the two that traders verify on Solscan.