Token burning.
Sending tokens to an address nobody holds the key to, with a permanent public record of it. Final from our side, though whether it truly reduces supply depends on the token.
The Robinhood Chain burn address#
Robinhood Chain has no special burn address of its own. It uses the same convention as Ethereum and every other EVM chain: the "dead address", an address nobody holds a private key for.
0x000000000000000000000000000000000000dEaDTokens sent there can never be moved again, because moving them would need a signature from that address. It has no contract code, so nothing can act on its behalf either. ETH sent there is just as stuck: on 10 October 2026, at block 85,143,863, it held about 2.28 ETH that nobody can ever spend. It is the address HoodLock's burner sends to, and the one most burn claims on Robinhood Chain refer to. You can look it up yourself on Blockscout. To see what a specific token has burned through HoodLock, paste its address into the burn checker.
Why not the zero address?#
The other address people reach for is 0x0000000000000000000000000000000000000000, often
written address(0). On most tokens you cannot send to it at all. OpenZeppelin's ERC-20, which
the large majority of tokens are built on, rejects a transfer whose receiver is the zero address: version 5
reverts with the custom error ERC20InvalidReceiver(address(0)), and older versions revert with
"ERC20: transfer to the zero address". The zero address is reserved for minting and burning
inside the token itself, which is why a wallet transfer to it fails and the dead address exists as the
workaround.
Dead address versus a real burn()#
| Send to 0x…dEaD | Call the token's burn() | |
|---|---|---|
| What it is | An ordinary transfer to an address nobody controls | A function on the token that destroys the balance |
totalSupply | Unchanged. The tokens still exist, parked where nobody can spend them | Decreases by the amount burned |
| Event emitted | Transfer(you, 0x…dEaD, amount) | Transfer(you, 0x0, amount) |
| Works on | Any standard ERC-20 | Only tokens that implement it, such as OpenZeppelin's ERC20Burnable |
| Reversible? | Not by any wallet. A mintable or upgradeable token can still change the picture | Same caveat: a mintable token can mint again |
So a dead-address burn removes tokens from circulation, but a "% of supply" figure still counts them in
the denominator. Circulating supply is totalSupply minus the dead address's balance.
What HoodLock's burner does#
The burner (contract and functions) calls
transferFrom(you, 0x…dEaD, amount) on the token, so it is a dead-address burn, not a call to
the token's burn(). totalSupply does not change. The tokens move from your wallet
to the dead address in that one call and never rest in the burner. It measures the dead address's balance
before and after, records the amount that actually arrived (so fee-on-transfer tokens are recorded
correctly), adds it to totalBurnedOf(token) and emits
Burned(id, burner, token, amount). It works on any standard ERC-20, whether or not the token
has a burn function.
How a burn looks on Blockscout#
- In the transaction, the token transfer reads from your wallet to 0x000…dEaD. For a burn through HoodLock the transaction is sent to the burner contract and its logs include the
Burnedevent. - On the token's holders tab, 0x000…dEaD appears as a holder. That balance is the running total of everything sent there, by anyone, not only through HoodLock.
- A real
burn()instead shows a transfer to the zero address, which Blockscout labels as a token burn, and the token's total supply on its page goes down.
Lock Uniswap v3 and v4 positions, do not burn them. A v3 or v4 LP position is an NFT, and the trading fees it earns can only be collected by whoever holds it. Sent to the dead address, the liquidity is permanent but every fee it earns from then on is stranded forever. The Liquidity Locker holds the position until a date you choose while you keep collecting its fees. Check an existing one with the liquidity lock checker.
What happens#
The burner moves tokens from your wallet to the dead address in a single transfer and writes a record: who burned, which token, how much, and when.
0x000000000000000000000000000000000000dEaDThe tokens never rest in the burner contract. There is no intermediate custody step where something could go wrong or where a privileged function could intervene. The transfer goes straight from you to an address nobody holds the key to.
We cannot undo this. There is no recovery, no support ticket and no admin override. The dead address has no owner, so there is no one to ask. Burn the amount you mean to burn.
What a burn does and does not prove#
This is the part worth reading carefully, because burning is routinely presented as stronger evidence than it is.
A transfer to the dead address does not reduce totalSupply. The tokens are
parked at an unspendable address, not destroyed at the protocol level, so every "% of supply" figure still
counts them in the denominator unless the token implements a real burn.
And the token decides whether they stay there. A mintable token can re-issue the same amount. An upgradeable token can add a function that moves the dead address's balance. Neither is visible from the burn record.
The recorded amount comes from the token itself. The registry measures the dead address's balance before and after, which means a token that reports whatever it likes can produce a burn record for far more than was actually sent. A burn of a token you did not verify is a claim, not proof.
Before treating any burn as supply reduction, including one shown to you, check the token's contract address rather than its symbol, and check whether it is mintable or upgradeable. How to read a contract on Blockscout.
Why burn through a contract at all#
You could send tokens to the dead address yourself. The difference is the record.
- A direct transfer is one line in a long transaction list that a reader has to find and interpret.
- A burn through the registry produces an indexed record and a proof page that states the amount, the share of supply it represented, and the transaction. Someone who has never used a block explorer can read it.
totalBurnedOf(token)gives a running total per token, so repeated burns add up to a number you can point at.
Where the line falls#
| A burn record establishes | It does not establish |
|---|---|
| That a transfer to the dead address happened, on a specific date, in a specific transaction | That totalSupply fell, unless the token burns rather than parks |
| That HoodLock cannot return those tokens | That the token cannot return them |
| That the burner gave up whatever they actually held | That what they held was worth anything |
| An amount the token reported | That the amount is true, if the token is not verified |
| Nothing about the remaining supply | Nothing about the token contract or the team |
On a verified, non-mintable, non-upgradeable token a burn is one of the strongest signals available, precisely because there is no way back. That qualifier is doing real work in that sentence, and it is why the checks above are worth the two minutes.
Burning versus locking liquidity#
For an LP position the two are genuinely different promises. A burn is permanent and needs no trust at all; a lock is temporary and keeps the option to migrate the pool later. Neither is strictly better, and the comparison lays out when each fits.
If you are considering burning LP to prove liquidity is permanent, first check whether the platform you launched on already locked or burned the position. You cannot burn a position you no longer control.
Cost#
A flat fee in ETH, read live from the contract, plus gas. Overpayment is refunded. No percentage of the tokens. The current amount is on fees.
Doing it#
Full steps in how to burn tokens. Burning is part of the Token locks screen: pick the FOREVER · BURN chip where you would normally choose a lock duration. You approve the token and then burn it. If your wallet supports batching, both go through with one signature, and the approval is skipped when your allowance already covers the amount.
The form shows your amount as a share of supply, and the confirmation screen repeats the amount and the dead address before you sign.
Burn tokens
Open Token locks and pick the FOREVER · BURN chip instead of a duration. One hop to the dead address, with a proof page and a transaction anyone can check.
Open Token locks →