A Token Burn Is One of the Few Crypto Claims You Can Check Yourself. We Checked All 2,735 of Them on This Token.

Almost nothing a crypto project says about itself can be checked. Roadmaps, partnerships, “utility coming soon”, the size and enthusiasm of a community: all of it is assertion. A token burn is the rare exception. A real burn changes a specific number in a specific place, that number is public, and reading it costs nothing.

Which makes it strange how rarely anybody looks. Burns get announced, screenshotted and celebrated, and the announcement is usually where the story stops.

So we ran the check properly on the token this site follows. Not the headline figure, which this site has quoted more than once, but every individual burn since launch: what was destroyed, when, by whom, and whether the total reconciles against the chain. It does reconcile. What it reconciles to is not what the headline figure implies.

A burn is an instruction, not a gesture

Every token on Solana has a mint account, and that account holds a field recording how many units exist. A burn is an instruction that reduces it. Solana’s own documentation puts it in one sentence: “Burning tokens permanently decreases a token account balance and reduces the mint’s total supply by the same amount.”

You can see the same thing in the token program’s source, which subtracts the burned amount from the mint’s supply field and fails the whole transaction if the arithmetic would not work. There is no separate ledger of destroyed tokens, no burn wallet holding them in escrow. The units stop existing, and the count goes down.

Reading that count takes one call. The method is getTokenSupply, it is free, it needs no account, and the documentation describes it as returning “the current supply for an SPL Token mint”. Asked about this token on 21 August 2026 at slot 440,672,649, a Solana mainnet node returned 964,167,105.851029 tokens.

That is the entire basis of the check. The number is not an estimate, it is not aggregated from exchanges, and nobody publishes it on the project’s behalf. It is a field, and you are reading it.

Not everything called a burn is one

Here is where most burn announcements get away with it. There are two completely different things people describe with the same word, and only one of them touches the supply.

The first is the real thing: a burn instruction, which destroys the units and decrements the mint. The second is sending tokens to an address nobody holds the keys to, often called a dead address or a burn address. That is a transfer. The tokens still exist. Supply does not move by a single unit. The claim can be perfectly sincere and still be describing something other than what the audience hears.

Neither is dishonest by nature, and the second is a legitimate technique on chains where burning is awkward. But they need different checks, and the difference matters because only one of them is irreversible in the strong sense. Keys to a dead address are almost certainly lost. Almost certainly is a different claim from cannot exist.

On this token the question settles quickly. The address most commonly used as Solana’s incinerator holds no $CATE at all: asked for that owner’s token accounts for this mint on 21 August 2026, the node returned an empty list. Nothing has been parked anywhere. Every token that has left this supply left it through the instruction that actually destroys tokens.

So we counted every one of them

A single supply reading proves the current state. It does not tell you how the supply got there, and the interesting question is always the how. So rather than diff two readings, we enumerated the burn events themselves.

The method is unglamorous. Solana’s full transfer history is indexed, burns are recorded as their own action type, and the token’s mint address filters the rest of the chain away. Every burn event on this mint from launch on 26 July 2026 through the morning of 21 August 2026, with the amount, the timestamp and the account it came from. The query is kept with the rest of this site’s research so anybody can rerun it.

The answer: 2,735 burn events destroying 35,832,886.009982 tokens, or about 3.58% of the launch supply of one billion.

That total is close enough to the figure this site and others quote that the headline survives contact with the data. What does not survive is the impression the headline gives, because the moment the burns are spread across a calendar rather than added into one number, they stop looking like a programme and start looking like a single event with a very long tail.

Ninety-nine percent of it happened in five and a half minutes

Rank the burns by the account they came from and the distribution is almost comically lopsided. One account is responsible for 35,587,738.967114 tokens, which is 99.32% of every $CATE ever destroyed. It did that in 28 events, all of them on launch day.

That account is HMzvsEEm…7ca3, and it is not a person. Asked what program owns it, the node answers pAMMBay6…fXEA, which pump.fun’s public documentation identifies as the address of the PumpSwap automated market maker. The account is the token’s own liquidity pool.

Pull one of those 28 transactions and the program log names the instruction outright: BoostBuyAndBurn. It appears in pump.fun’s published interface definition as boost_buy_and_burn, taking an amount to spend and a minimum quantity to destroy, drawing on an account the definition calls the boost vault. In plain terms: capital from the migration itself is spent buying the token on the open market, and everything it buys is destroyed.

The launchpad announced the feature on 21 July 2026, five days before this token existed, describing it as “the new standard launch mechanism for EVERY new pump fun coin” and pitching it at the roughly $100 million a year it says goes dead when tokens migrate. Reporting at the time put the buyback window at five minutes after migration, the allocation at about 17.6 SOL for a SOL-paired token, and the activation as automatic, with nothing for a project to opt into.

The timestamps fit that description exactly. The pool was created at 16:32:43 UTC on 26 July 2026. The first burn landed two seconds later at 16:32:45, the last at 16:38:22, and the 28 of them ran for five minutes and thirty-seven seconds. The largest destroyed 2,725,922 tokens, the smallest 626,038. Then it stopped, and it has never run again.

What the other 0.68% is made of

Strip out the pool and 245,147 tokens remain, spread across 2,707 events. Almost all of that is one afternoon’s work by one wallet.

On 4 August 2026 a single address burned 200,643.346249 tokens in one event, which is 0.56% of the all-time total and more than everything else outside the pool combined. It is an ordinary wallet, owned by the system program rather than any contract, which means a person or a script with a keypair chose to do it. Nothing about it was announced anywhere that we can find, which is worth sitting with: the largest deliberate human burn this token has had went completely unremarked, while burns elsewhere in the market get press releases.

What is left after that is 44,504 tokens across 2,706 events, and the shape of it tells you what it is. In the seven full days from 14 to 20 August there were 217 burn events destroying 1,431 tokens between them, a median of about 201 tokens a day. On 5 August alone, 1,033 separate events destroyed 1,181 tokens, which is roughly one token each. That is not a deflation policy. That is dust, wallets being tidied, token accounts being closed out, and the ordinary residue of a lot of people trading.

The two numbers have to agree, and they nearly do

Here is the part that turns a list into a verification. There are two independent routes to the same quantity, and if the burns are real the routes have to meet.

Route one is arithmetic on the supply. The token launched with one billion units. A node today reports 964,167,105.851029. Since the mint authority is empty, nobody can have created any along the way, so the entire difference has to be burns: 35,832,894.148971 tokens.

Route two is the count we just built from the transfer history, event by event: 35,832,886.009982 tokens.

The two land 8.14 tokens apart, out of a billion. That is a gap of eight parts in a billion. Measure a lap of the planet to that tolerance and you would be arguing about a single footstep.

The residual also points the right way, which matters more than its size. The event count is short of the supply arithmetic, meaning the chain has seen burns the index has not caught up with yet, and the last day in the data is visibly partial: six events, against thirty or forty on a normal day. A live node is always ahead of an indexer. Had the numbers missed in the other direction, with more burns counted than the supply can account for, that would be a genuine problem and the honest conclusion would be that something in the method was wrong.

How to run this on any token

Nothing above is specific to this token. The check is three steps and none of them require trusting anybody.

First, read the supply. One free call to a public node with the mint address returns the current count, and it is the same answer for everyone who asks. Second, check the authorities on the same account. If the mint authority is not empty, stop, because a supply that can be refilled makes a falling supply meaningless. Third, compare against the claim. If a project says it destroyed a specific quantity on a specific date, the supply has to be lower by that quantity, and if it is not then whatever happened was not a burn instruction.

Where you want the detail, the transfer history gives you the events themselves, which is how you find out whether a burn was a project decision, an automated launchpad feature, or two thousand people closing empty accounts. Our own article on circulating supply covers the neighbouring trap, which is that the supply figure a tracking site displays is often not the one the chain holds.

Two things this check will never tell you, and it is worth being blunt about both. It says nothing about what a burn does to price, because supply is one input among many and this site does not forecast prices. And it says nothing about whether more burns are coming, because past instructions are a record, not a schedule.

What the check was actually worth

The headline held up. Roughly 35.8 million tokens really were destroyed, the supply really is about 964.2 million, and nobody can create more. Every claim this site has made on that subject survived being examined, which is the outcome you hope for and should never assume.

But the check also changed what the number means. “Thirty-five million tokens burned” sounds like a policy, something the project keeps doing. It was a launchpad feature that fired automatically for five and a half minutes on the first afternoon and has not run since, plus one anonymous wallet, plus a month of dust. That is not worse. It is just different, and anybody deciding what the figure tells them about the project deserves to know which one it is.

That gap between a true number and the story it implies is the reason to check things yourself. The live figures for this token, read from the chain hourly, are on the stats page, and the five checks that actually matter covers the rest of what is worth verifying before you go anywhere near a token.