Glossary · Ethereum and tokens

Zero address

Published 24 May 2025 · Updated 20 Oct 2026 · 9 min read

The zero address is the all-zero, 20-byte address used on Ethereum and other EVM chains. Written as 0x0000000000000000000000000000000000000000, it is also called the null address. No one is known to hold its private key. Token contracts use it to mark creation or destruction in event logs.

  • The zero address contains 20 zero bytes and has no known private-key holder.
  • In token events, it can mark minting or burning rather than a payment.
  • Never send funds to the zero address. Nothing sent there can be moved again.
What the zero address isWhere the zero address appearsBurning and the zero addressAvoiding zero address mistakesThe zero address on other blockchainsGuarding against zero address errorsGetting zero-address handling rightZero address FAQ

What the zero address is

An Ethereum account address is a 20-byte (160-bit) value, written as 0x followed by 40 hexadecimal characters. The zero address, 0x0000000000000000000000000000000000000000, fills every position after 0x with zero. Its value is identical across EVM-compatible networks, not unique to the Ethereum network. No one is known to hold its corresponding private key, so funds sent there cannot be moved. In Solidity, an address variable starts with an all-zero default value unless another value is assigned.

The dead address, 0x000000000000000000000000000000000000dEaD, is a vanity address used to remove tokens from circulation. It is not the all-zero value. Low-numbered addresses can identify precompiled contracts instead. The precompile at 0x01 performs ecrecover signature recovery, but address zero is not a precompile. When recovery fails, ecrecover returns zero. OpenZeppelin's ECDSA library treats that result as an invalid signature.

Figure 1 · Sample addressesCompare four address typesSelect each address to compare its purpose, who controls it, and whether it belongs in a payment's recipient field.
0x0000000000000000000000000000000000000000
0x000000000000000000000000000000000000000020 bytes · 40 hex characters · 0 non-zero bytes
What it isThis is the all-zero, 20-byte value used across EVM chains.
Private keyNo one is known to hold its private key.
Typical useIt marks token events and empty address values.
Send funds here?Do not send funds to this address.

Where the zero address appears

This value commonly appears in four places. It can be the sender of new tokens, the recipient of burned tokens, or the owner of a contract that gave up ownership. It is also the empty value of an unset variable. Each case means something different, and an event alone cannot show which contract function ran.

Minting ERC-20 tokens

For the ERC-20 token standard, EIP-20 says minting should emit a Transfer event from the zero address. OpenZeppelin's _mint emits it and increases totalSupply.

Minting and burning NFTs

Under EIP-721, the ERC-721 token standard, Transfer records NFT creation from zero and destruction to zero. EIP-1155 requires zero senders for minting and zero recipients for burning.

Renouncing contract ownership

Ownable.renounceOwnership sets the owner to address(0), leaving no owner. Readers then see an empty owner address, and onlyOwner functions can no longer be called.

Spotting unset values

A developer sees address(0) when a variable was never set. Code sending value to it sends funds to the zero address. Foundry's example uses a "to" variable that defaults to address(0), burning all ETH.

Figure 2 · Sample token: PLXFollow the PLX event logFilter six PLX events, then select an entry to distinguish two mints, two regular transfers, one burn, and one dead-address transfer.
Minted (from 0x0)1,500
Burned (to 0x0)100
totalSupply1,400
Held by 0x…dEaD50
Event 1 · Transfer(0x0000…0000, 0x5aAe…eAed, 1,000)The sender is zero because PLX is being created. This entry records issuance, not a payment from another holder.totalSupply after this event: 1,000

PLX is a sample token, and all addresses shown are examples.

Burning and the zero address

A supply reduction happens inside the token contract. In OpenZeppelin ERC-20, _burn lowers totalSupply and emits Transfer to the zero address. A transfer to the dead address changes balances without changing totalSupply. Some trackers subtract that address's holdings when reporting circulating supply. Their circulating figure is not the same as the contract's totalSupply.

Most current token contracts refuse a plain transfer to the zero address. OpenZeppelin Contracts 5.x reverts with ERC20InvalidReceiver. A burn showing it as the recipient comes from a burn function, not an ordinary transfer. Under EIP-1559, the protocol burns the base fee of every Ethereum transaction. It removes that ETH from circulation without sending it to any address.

Figure 3 · Sample ERC-20 on OpenZeppelinCompare three token outcomesTry each action with a holder balance and totalSupply of 1,000 PLX. Compare supply reduction, balance movement, and a rejected transfer.
Holder balance0x5aAe…eAed1,000no change
Dead address0x0000…dEaD0no change
Zero address0x0000…00000no change
totalSupplytoken contract1,000no change
No call yet. Pick one of the three calls.Holder 0x5aAe…eAed starts with 1,000 PLX. totalSupply is 1,000.

Each action restarts from identical balances in this sample contract.

Avoiding zero address mistakes

An address can look familiar without being safe. The EIP-55 checksum uses letter case to detect typing errors, not recipient identity. The all-zero value has no letters, so casing cannot protect it. Verification needs more than a matching prefix or suffix.

Irrecoverable recipient mistakes

Most token contracts refuse plain transfers to the zero address, but wallets can send native ETH, the network's own cryptocurrency, there. Code with an unset address variable can send value there by default.

Missing address validation

A setter that accepts address(0) can disable an owner or admin role, or misdirect treasury funds. Slither and Foundry flag missing zero-address checks with Low severity.

Poisoned transaction history

A USENIX Security 2025 paper counted 270 million address poisoning attacks against 17 million victims on Ethereum and BNB Smart Chain over two years. Losses reached at least $83.8 million.

Misclassified token activity

Tools tracking a blockchain token can count a mint as a payment or a burn as a sale. Ignoring the event's mint or burn marker distorts analytics, tax, and portfolio records.

Figure 4 · Sample addressesCheck a sample recipientSelect each proposed recipient to compare a saved contact, a lookalike, unrecoverable destinations, and a checksum mismatch.
Recipient
Wallet iconSend 0.50 ETHSaved contact: 0xD122…9aDb
To0xD1229b3E5c08aF41e7D2c96B05f1A84c3E7e9aDbFirst 4 and last 4 characters match the saved contact. 26 of 40 characters differ in between.
CheckThe first four and last four characters match the contact, but the middle differs. Treat it as a poisoning attempt.

These are sample addresses, and no funds are sent.

The zero address on other blockchains

The null address is an EVM convention, not a universal destination. A blockchain network may use program IDs, unspent outputs, or party identifiers instead of EVM accounts. Each network uses its own rules to burn assets through an address, an instruction, or a contract operation.

ChainZero or null addressHow burns usually work
EVM chainsZero or null addressThe zero address is the same 20-byte value across EVM chains.How burns usually workToken contracts use burn functions, while EIP-1559 burns Ethereum transaction base fees without a recipient.
SolanaZero or null addressThe System Program ID, 11111111111111111111111111111111, encodes 32 zero bytes and identifies a program, not a burn address.How burns usually workSPL tokens use a Burn instruction. Lamports sent to the incinerator are removed from supply at block end.
BitcoinZero or null addressBitcoin uses unspent outputs, or UTXOs, so it has no account-style zero address.How burns usually workOutputs using OP_RETURN are provably unspendable and can burn bitcoin.
CantonZero or null addressParties use names and key fingerprints, so Canton has no zero address.How burns usually workAssets are Daml contracts. CIP-56 holdings are retired by archiving, while validators burn Canton Coin for fees.

On the Bitcoin network, 1111111111111111111114oLvT2 pays to an all-zero 20-byte public key hash. In October 2026, mempool.space shows about 810 BTC received and none spent, while the vanity address 1BitcoinEaterAddressDontSendf59kuE has received about 13.4 BTC.

Guarding against zero address errors

This example, written in the Solidity language, validates a proposed address before the setter accepts it. The custom error ZeroAddress signals that the new value equals address(0). A separate burn function calls _burn instead of transferring tokens to an inaccessible recipient. The setter rejects an unusable address, while the burn function deliberately reduces token supply.

Solidity · sample
// Reject the zero address where it would lock funds or roleserror ZeroAddress();
function setTreasury(address newTreasury) external onlyOwner {    if (newTreasury == address(0)) revert ZeroAddress();    treasury = newTreasury;}
// _burn lowers totalSupply and emits Transfer(from, address(0), amount)function burn(uint256 amount) external {    _burn(msg.sender, amount);}

Tests should check that zero inputs fail and burns update balances, supply, and events correctly. A smart contract audit can also check setters for empty addresses that would disable owner or admin controls.

Getting zero-address handling right

Handling empty addresses involves more than adding one guard clause. A smart contract development plan should cover recipient validation, token supply rules, ownership changes, event interpretation, and testing. The code and the records users see should tell the same story. Specify what happens when a transfer fails, tokens burn, or ownership changes.

PixelPlex case icon

We built the Coindepo ERC-20 token ecosystem around a utility token with vesting cliffs and linear release schedules. We deployed the token to Ethereum mainnet in three weeks, and the contracts were audited by CertiK.

  1. Recipient validation

    Owner, admin, and treasury setters need explicit input rules. Reject address(0) wherever an empty value would disable control or misdirect funds.

  2. Supply and balances

    A token development plan should separate mint and burn paths from transfers, with explicit expectations for balances and totalSupply.

  3. Ownership changes

    Treat renounceOwnership as an intentional loss of owner control. OpenZeppelin Ownable rejects address(0) in transferOwnership, rather than treating it as renunciation.

  4. Event interpretation

    Record mints, burns, and holder-to-holder transfers separately. Include dead-address transfers without mislabeling them as reductions in totalSupply.

  5. Verification coverage

    Test rejected inputs alongside valid operations. Check that expected reverts leave balances unchanged and that burns produce the intended supply and events.

Discuss address handling in your token contracts

We can review setters, mint and burn paths, and tests with your team before mainnet deployment.

Discuss your project

Zero address FAQ

Does anyone own the zero address?

No known private-key holder controls the zero address. Etherscan labels it "Null: 0x000...000" and describes it as not owned by any user. In October 2026, the explorer shows thousands of ETH and hundreds of different tokens there, mostly from burns and mistakes.

Does sending ETH or tokens there burn them?

Sending ETH to the zero address runs no burn logic, but that ETH can never move again. Most current token contracts, including OpenZeppelin implementations, reject plain transfers there, so tokens stay with the sender. A real burn goes through a burn function that lowers totalSupply and emits a Transfer to the zero address.

Is it the same as the dead address?

No. The dead address is 0x000000000000000000000000000000000000dEaD, a vanity address that Etherscan labels "Burn". Tokens sent there leave circulation but still count in totalSupply. The zero address is the all-zero value that marks mints and burns in token events.

Why do mints show "from 0x000..."?

Because the tokens are new. EIP-20 says a mint SHOULD emit a Transfer event from zero. EIP-721 uses the same marker, and EIP-1155 makes it a MUST. The explorer shows a sender, but no one sent anything.

Are contracts deployed to the zero address?

No. A contract deployment transaction has no recipient at all, and its data field carries the contract code. The new contract's address is derived from the sender and its nonce. A missing "to" field is not the same as a transfer to 0x000...000.

Can funds sent there ever be recovered?

No. No one is known to hold a key for the zero address or the dead address, so nothing sent there can move again. If a token contract rejects the transfer, tokens stay with the sender. Only the network fee for the failed transaction is spent. Check the full address before sending.

What is a zero-value transfer scam?

An attacker calls transferFrom with an amount of zero, which creates a real Transfer event from the victim's address. EIP-20 requires zero-value transfers to fire the event like any other. The goal is to plant a lookalike address in the victim's history, hoping it gets copied for the next real payment. The victim signed nothing. Etherscan hides these entries by default.

Related terms

All definitions
Sources (25)

Get updates about blockchain, technologies and our company

We will process the personal data you provide in accordance with our Privacy policy. You can unsubscribe or change your preferences at any time by clicking the link in any email.

Follow us on social networks and don't miss the latest tech news

  • facebook
  • X
  • linkedin
  • instagram
Stay tuned and add value to your feed