Skip to main content
Self-burn authenticates the caller as the account being burned. Delegated burn (burnFrom) authenticates the caller as the spender and enforces a prior allowance. Both use the witness-derived keypair pattern from Access Control.

The Contract

How It Works

Self-burn authenticates the burner

The caller proves knowledge of the secret behind the account whose balance is being burned. Reading the chain gives an attacker the hash of the secret, not the secret itself.

burnFrom enforces an allowance

Same idea as transferFrom but the destination is the burn (no to parameter). The spender must have a non-zero _allowances[account][spender] entry of at least amount.

Invariants

  • currentBalance >= amount — caller can’t burn more than they hold.
  • _totalSupply >= amount — defensive check; should always hold given the previous invariant, but cheap to assert.
  • Both writes happen in sequence so sum(balances) == _totalSupply stays true.

Privacy Note

Each burn writes account and amount to the public ledger. The account-model design is deliberately transparent. For private deflationary mechanisms, use shielded primitives where amounts and identities stay in ZK-committed UTXOs.

What’s Next

Minting Tokens

Learn how to create new tokens

ERC20 Token

Complete token with burning