CAKE’s cap is 400 million. Its contract says 5.09 billion

Most of the disagreements this desk writes about are between what a project says and what its chain did. This one is between a chain and everybody downstream of it. Ask the CAKE contract how much CAKE exists and it answers 5.09 billion. Ask PancakeSwap and the ceiling is 400 million — not a marketing figure but a hard cap, voted on, with the proposal still readable. Ask CoinGecko and the total is 333 million, of which 321 million circulates. This desk publishes 339 million. Five numbers, a factor of sixteen apart, and not one of them is wrong.

The cap, and the counter

The cap first. CAKE has one, and it moved recently: a proposal voted between 16 and 19 January 2026 cut it from 450 million to 400 million and carried with effectively no opposition. That is the ceiling the project holds itself to, and it is a real constraint rather than a slogan — it was lowered rather than raised.

Now the contract. Reading totalSupply() from the CAKE token on BNB Smart Chain at block 117,691,971 returns 5,091,646,851.75 — nearly thirteen times the cap the project says it obeys. Nothing has been breached, and nobody is misreporting anything.

Where the other 4.75 billion is

It is at one address, and it has not moved since it arrived. 0x0000…dEaD held 4,752,225,304.31 CAKE at the same block — 93.3% of everything the contract counts.

That address has no known key, so the tokens in it are unreachable by anybody, for ever. But it is an ordinary account, and sending tokens to it is an ordinary transfer. The contract’s counter is never touched, so from totalSupply’s point of view nothing has been destroyed at all — the tokens simply have a new owner who will never spend them. This is the fourth of the six destinations in where burned tokens go, and CAKE is the largest example the register holds.

It is worth separating this from the failure mode it superficially resembles. An optical burn is a burn of tokens that were never circulating: the total falls, the announcement is impressive, and no holder is any less diluted. CAKE is the mirror image. The tokens were bought on the open market, so they genuinely left circulation and every holder is less diluted for it — and the total does not fall. One of them looks better than it is; the other looks worse.

PancakeSwap says this itself

The desk did not work this out against the project. PancakeSwap’s own tokenomics page carries a section headed “How to Confirm CAKE Supply for yourself”, and its instruction is to look up what the burn address holds and then “subtract this burned amount from the ‘Total Supply’ that BscScan shows”. That is exactly the calculation above, published by the project, on the page a reader would reach first.

CAKE Tokenomics | PancakeSwapdocs.pancakeswap.finance

And the aggregators follow it. CoinGecko publishes 333.49M total and 321,214,919 circulating; CoinMarketCap publishes 333.49M and 321,214,920. That is one token apart in three hundred and twenty-one million, which is not what two houses agreeing looks like — it is what one figure looks like when it is republished. Two parties doing this work separately would have to make the same call on the legacy pool, the same call on which wallets are the project’s, and read at the same moment; they would land close, not adjacent. So the pair is evidence that the corrected figure travels downstream, and not evidence that anybody checked it twice. What it does show is the shape of this article: nothing is concealed, the project documents the correction on the page a reader reaches first, and the figure the sites publish is the corrected one.

What none of them can do is change what the chain returns. totalSupply() answers 5.09 billion to anybody who asks it — a screener wiring up a new listing, a dashboard computing a market cap, a model reading contracts rather than price pages. The instruction in PancakeSwap’s own documentation is the proof that this is a live problem rather than a theoretical one: telling readers to subtract the burn address from the total only makes sense because the total they will meet has not had it subtracted.

The smaller steps in the ladder are worth naming too, because they are the ones that look like errors and are not. Our 339,421,547 sits about six million above CoinGecko’s total, and that difference is the legacy pool this article’s caution below describes. CoinGecko’s own total sits about twelve million above its circulating figure, which is the ordinary distinction between tokens that exist and tokens in somebody’s hands. Neither gap is a disagreement about the chain; both are disagreements about the question.

What the programme actually did

The same page states a target: “an annual deflation rate of at least ~4% per year”, with burns funded from a share of fees across spot trading, perpetuals, the launchpad and the lottery. So there is a published claim, and it is the kind that can be measured rather than argued about.

And the project has published a figure of its own against it. The post that opened the discussion on reducing the cap says CAKE achieved a net burn of about 8.19% across 2025, and offers that as the reason to lower the ceiling.

PancakeSwap@PancakeSwap

🥞 Discussion of Proposal to Reduce CAKE Max Supply Following the rollout of CAKE Tokenomics 3.0, CAKE’s token supply has achieved a net burn of ~8.19% in 2025 Given this momentum, the Kitchen is proposing to: 🔹 Reduce CAKE’s max supply from 450M to 400M CAKE 🤝Your feedback https://t.co/IqfJXSSodP

That figure and ours are not the same measurement and should not be added together: theirs covers 2025, ours covers 2026 so far, and a "net burn" counted against a supply is sensitive to which supply is meant. What can be said is that both sit above the stated target, and that the later of the two is the smaller — which is what a burn funded by fees looks like when the base it is measured against has itself been shrinking.

Our supply series for CAKE begins on 14 January 2026, when the tradeable figure was 352,806,113. On 23 August it was 339,421,547. That is 3.79% over 221 days, which annualises to 6.2% a year — comfortably ahead of the target the project set for itself.

The line falls gently and the contract’s own number rose by 1.7 billion over the same months. Both describe the same seven months of the same programme.

Checked twice, and where it is thinner

A rate matters more than most figures here, so it is worth saying how far it can be trusted. For June, July and August the desk holds the burns as individual transactions rather than as differences between balances — and in each of those three months the transfers sum to exactly the movement in the burn address: 297,024,128 in June, 237,400,093 in July, 179,309,132 in August, with no remainder in any of them.

Those are two measurements that share no method — a balance read at two moments, and a set of transfer events collected one at a time — landing on the same number three months running. Before June the desk holds derived rows rather than transactions, which is why the rate above is anchored on the balance series, which covers the whole period, rather than on the event count, which does not.

It is not only CAKE

CAKE is the extreme rather than the exception. The same arithmetic applies wherever a project burns by sending tokens to an address with no key, and the table below is two chain readings per token — what the contract counts, and what sits at the burn address — with the subtraction between them. Nothing in it is an estimate, and anybody can repeat all of it.

GT is worth pausing on, because it shows how the correction actually travels. CoinGecko’s own note for it says its figure accounts for 189,947,219 tokens in a burn wallet — and the reading above, taken independently, is 189,947,220. The two agree to a single token. So the subtraction is not something this desk invented for CAKE; it is applied across the industry, token by token, by people who have looked at each contract and worked out what its number means.

Which is the point, and also the weakness. It is applied token by token, by hand, because nothing in the chain’s answer says it is needed. A contract that has burned nothing and a contract that has burned 93% of what it counts return the same shape of number, and only somebody who already knows the difference can tell them apart.

There is a second, unrelated reason a headline supply runs ahead of a tradeable one — supply that exists but has not been released, on a vesting or unlock schedule — and it points the opposite way. A gap made of burned tokens is behind the token: that supply is gone, and the total will drift further from the truth as more is burned. A gap made of unreleased tokens is ahead of it: that supply is coming, on a published schedule, and the total is the figure that will eventually be right. Telling them apart matters more than either number, and neither is visible in the number itself.

What to use

For CAKE the answer is around 330 million, and which of the near neighbours you take — our 339 million, CoinGecko’s 333 million, its 321 million circulating — depends on whether you want tokens that exist or tokens in hands. What none of them is, is 5.09 billion. The cap is a promise about the future, the contract’s figure is a counter that was never designed to answer this question, and everything useful lives in the subtraction between them.

🥞 PancakeSwap - Everyone's Favorite DEXTrade, earn, and own crypto on the all-in-one multichain DEXpancakeswap.finance

Every figure here was read on 23 August 2026, at BSC block 117,691,971. Supply figures age, and this article states its date for that reason rather than as a formality — the burn address grows by roughly two hundred million CAKE a month, and the fifteen-times gap in the headline will be wrong, in the same direction, by the time it is quoted.