Coin burning is the permanent removal of tokens from a cryptocurrency's supply. It is done in one of two ways. The tokens can be sent to an address that nobody can spend from, or a token contract can destroy them and lower its recorded total supply. Either way the tokens can never move again, and anyone can check the transaction on a public block explorer. Burning cuts supply. It does not guarantee anything about price.
The two largest recurring burns show how differently this can play out. On 19 October 2026, BNB Chain completed its 37th quarterly Auto-Burn and destroyed 1,646,196.44 BNB. Meanwhile, Ethereum's fee burn, which has been running since August 2021, now offsets only a small fraction of new ETH issuance.
The latest burns: BNB and ETH, October 2026
BNB (19 October 2026). According to BNB Chain's announcement, the 37th quarterly burn removed 1,646,196.44 BNB, valued at about $1.197 billion at the time of writing (10:05 UTC, 19 October 2026). Total supply was left at 131,512,085 BNB. The tokens went to the burn address 0x000000000000000000000000000000000000dEaD. BNB Chain says future quarterly burns will run directly on BNB Smart Chain (BSC). It also says it adjusted the parameters of the burn formula because the Lorentz and Maxwell upgrades made BSC produce blocks more often than the original formula assumed. The previous burn, the 36th, removed about 1,615,828 BNB and left about 133.17 million BNB.
ETH (17 October 2026). Since EIP-1559 went live on 5 August 2021, about 4,641,036 ETH has been burned. CryptoTicker reported that figure on 17 October 2026, citing ultrasound.money data. In the 24 hours it covered, 13.59 ETH was burned against about 2,969 ETH newly issued. That burn offset roughly 0.46% of issuance, so net supply grew by about 2,955 ETH that day. These figures come from one secondary report; we could not load the primary dashboards (ultrasound.money, beaconcha.in) to confirm them.
Taken together, the two cases show that a burn's size and rate depend on how it is designed. A burn tied to fee activity shrinks when fees fall.
How a burn works
Burn addresses
A burn address can receive tokens but never send them, because no one holds a key that can sign a transaction out of it. The most widely used one on Ethereum-compatible chains is 0x000000000000000000000000000000000000dEaD. Etherscan labels it "Null: 0x00...dEaD" with a "Burn" tag and describes it as "commonly used by projects to burn tokens." BNB Chain uses the same address for its quarterly burns.
Bitcoin has a cleaner tool. An output script built with OP_RETURN (a "null data" output) is, in the words of the Bitcoin developer guide, "provably unspendable." Any satoshis sent to such a script can never be recovered. In standard null data outputs, though, the value is zero, because the script is meant for carrying data.
Contract-level burns that reduce recorded supply
Sending tokens to a dead address and destroying them in the token contract are technically different:
- Transfer to a burn address. Under the ERC-20 standard (EIP-20),
transferjust moves a balance from one address to another. The contract'stotalSupplydoes not change. The tokens are stuck, but they still count in the contract's own supply figure. Data sites have to subtract the burn-address balance themselves. - Contract burn function. OpenZeppelin's widely used ERC-20 implementation has a
_burnfunction that destroys tokens, "lowering the total supply," and emits aTransferevent to the zero address. ItsERC20Burnableextension exposesburn(burns the caller's own tokens) andburnFrom(burns another account's tokens up to the allowance the caller has been given). - Solana. The SPL token burn instruction "permanently decreases a token account balance and reduces the mint's total supply by the same amount." The account owner or an approved delegate signs the burn.
This difference is why a token's "total supply" and "circulating supply" can disagree after a burn, depending on which method was used and how a data site counts it.
Manual, automatic and protocol-level burns
| Model | Who triggers it | What you have to trust |
|---|---|---|
| Manual | The project team, when it chooses | That the team sent tokens to an unspendable address and in the amount announced |
| Rule-based or formula-driven | A published formula or contract logic | The formula, the code, and whoever can change either |
| Protocol-level | The chain's consensus rules, every block | The chain's upgrade process |
BNB Auto-Burn is formula-driven. The quarterly amount is set by the formula B = N × 1000P + K. Here N is a block count normalised to 3-second blocks, P is the quarter's median BNB/USD price, and K is a price anchor initially set to 1,000. The aim is to cut total supply to 100,000,000 BNB. Separately, under BEP-95, a share of gas fees in each block is burned in real time, at a ratio set through validator governance. As the October 2026 adjustment shows, the formula's parameters can be changed.
Ethereum's EIP-1559 burn is protocol-level. Every transaction pays a base fee, and the spec states that "the base fee is always burned (i.e. it is destroyed by the protocol)." Only the priority fee goes to the block producer. The base fee rises or falls each block depending on how full the previous block was compared with its gas target. The spec sets a maximum change of 1/8 per block (BASE_FEE_MAX_CHANGE_DENOMINATOR = 8). No team decides when this burn happens. Changing it would take a network upgrade.
Why projects burn tokens
- To offset issuance. A burn counters new supply from rewards or emissions, but only to the extent of its size. In the hypothetical case of a token that issues 5 million tokens a month and burns 1 million, supply still grows. Ethereum in October 2026 is a real case: per the figures above, issuance far exceeds the burn.
- To retire unused allocations. Unsold or unclaimed tokens are destroyed, so they cannot be released later.
- To tie supply to usage. Fee burns like EIP-1559 link the amount destroyed to network activity.
- To create new tokens: proof of burn. Some systems issue a new asset to people who destroy an existing one. Counterparty's XCP was created this way. Between 2 January and 3 February 2014 (5,000 Bitcoin blocks), users sent BTC to the unspendable address
1CounterpartyXXXXXXXXXXXXXXXUWLpVrand received between 1,000 and 1,500 XCP per BTC. Earlier burns got more, and each address could burn at most 1 BTC.
Bitcoin itself has no burn mechanism for supply control. Its limit is built in: in bitcoin.org's words, "only 21 million bitcoins will ever be created."
Does a burn raise the insiders' share?
Enter a token's total supply, the insiders' holding and the number of publicly held tokens burned to see the insiders' share of what remains.
| Total token supply before the burn | Tokens held by insiders (not burned) | Publicly held tokens burned | Insiders' share of remaining supply |
|---|---|---|---|
| 1,000,000,000 tokens | 100,000,000 tokens | 600,000,000 tokens | 25 % |
| 1,000,000,000 tokens | 100,000,000 tokens | 0 tokens | 10 % |
| 1,000,000,000 tokens | 100,000,000 tokens | 600,000,000 tokens | 25 % |
- All three values are your own inputs; the defaults repeat the article's hypothetical project, not any real token.
- The burned tokens are assumed to come only from public holders, so the insiders' holding stays the same.
- The result is capped at 100% in case the insider holding entered is larger than the supply left after the burn.
This is arithmetic on your inputs only: it does not check whether a burn happened, how much new supply issuance or unlocks add, or what any token's price will do.
What burning does not do
A smaller supply is one input into price, alongside demand, liquidity and wider market conditions. A burn can coincide with a falling price, and a large burn can be outweighed by issuance.
A burn can also change who owns what. Take a hypothetical project with 1 billion tokens in which insiders hold 100 million. If 600 million publicly held tokens are burned, the insiders' 100 million becomes 25% of the remaining 400 million, up from 10%, without them buying anything. Before you take an announcement at face value, check insider allocations before and after the burn.
How to check a burn yourself
- Get the address or transaction from the project's own channels. That means its website, documentation or official announcement. A screenshot is not proof.
- Open it in the chain's block explorer. Use Etherscan for Ethereum, BscScan for BNB Smart Chain, or a Solana explorer such as Solscan.
- Check three things.
- The amount received matches the announcement. - The burn address has never sent anything out. - For contract burns, the token's total supply has dropped by the burned amount. Mint-and-burn events show up as Transfer events to or from the zero address.
- Compare the burn with issuance. Set the burned amount against the token's emission or unlock schedule for the same period.
Warning signs: no published address, burns timed to heavy promotion, and large insider holdings that grow as a share of supply after each burn.
Other supply tools, compared
| Tool | Reversible? | Effect on supply |
|---|---|---|
| Burn | No | Tokens permanently unusable |
| Hard cap (e.g. Bitcoin's 21 million) | Only via a protocol change | Limits issuance; removes nothing |
| Staking lock-up | Yes | Temporarily reduces liquid supply |
| Vesting | Partly; tokens release on schedule | Delays supply |
| Buyback | Yes, unless the tokens are then burned | Moves tokens to a treasury |
Limitations: the ETH burn figures come from a single secondary report of ultrasound.money data that we could not confirm directly, and live totals change with every block.
This article is for information only and is not investment advice.
