A burn announcement is out, but on-chain total supply hasn't budged—it's not necessarily the project team tricking you. More often, the "supply" you think of and the one actually affected by the burn are two different things.
Confirm Whether It's a Real Burn or Just a Lock into a Black Hole
This is the most common reason supply doesn't decrease. Both operations look on-chain like "transferring to an address no one can move," but they affect total supply very differently.
Case A: Burning via the token contract's native burn function — this operation directly reduces the totalSupply value. In Solana's SPL Token standard, when you burn tokens using the official BurnChecked instruction, the Mint account's totalSupply decreases accordingly; in the Ethereum ecosystem, a burn that triggers a Transfer(from, address(0)) event also reduces totalSupply.
Case B: Sending tokens to a "dead address" — such as 0x000...000 or 0xdead... . This only locks tokens in an address no one controls, but the token contract's totalSupply stays the same. On Solana, sending to a "dead address" removes liquidity but doesn't reduce the total supply. On-chain tracking tools usually read the totalSupply field, not attempt to figure out how many coins in an address are permanently unspendable.
Verification step: Check the burn transaction record to confirm whether the team used a burn() function or just sent tokens to an address that "looks like a black hole."
Distinguish Between "Burning Circulating Supply" and "Burning Unissued Tokens"
Another reason supply doesn't drop: the team is burning tokens that weren't even in circulation.
What to do: Confirm whether the burned tokens came from market circulating supply or from team reserves / locked allocations.
How to do it: Look at the "sender address" of the burn transaction. If the tokens were sent from a wallet that never entered the open market (like a developer reserve address), then it does reduce the "theoretical max supply," but the circulating supply trading on the market doesn't change. In SHIB's early days, there were cases where unissued supply was burned instead of circulating tokens—this kind of burn cannot create an immediate market impact.
Verification step: You have confirmed whether the burned tokens came from open-market purchases or from the team's own non-circulating inventory.
Spotting Common Fake Burns
Many so-called "burns" are actually "lock-ups" or "transfers to invalid addresses," with total supply unchanged. PEPE, for example, burned 210 trillion tokens early on to create a scarcity narrative, but later new issuance and dynamic supply mechanics meant the max supply remained 420 trillion. If the burn itself is a "fake burn"—for instance, claiming a burn without executing a transaction, sending tokens to a controllable address, or re-minting tokens after a burn—supply naturally won't decrease.
Even if you confirm a real on-chain burn, do the math. If the burn amount is only a few million tokens, but circulating supply keeps growing by tens or hundreds of millions each day (through unlocks, emissions), total supply will still rise—and the burn's price support gets diluted. AEVO has burned 74 million tokens, but its base logic is "fixed total supply of 1 billion, no new minting"—fundamentally different from projects that keep burning while also issuing more.
How to Verify On-Chain Burns in Practice
Find the burn transaction hash on a block explorer, click to see Event Logs. If you see a Transfer(from, 0x000...000, amount) event and the sender is a known public buyback address, that's a real burn. Also, check the token contract's totalSupply method before and after the burn to see if the number changed.
Follow-Up Tracking Tips
Add "burn source" and "whether total supply changed after a burn" to your checklist. If two weeks after a project announcement you still see no visible change in supply, check the balance of the burn address on a blockchain explorer. If tokens went in but total supply didn't change, what you saw was a "lock-up," not a real deflationary operation.
