ERC-721 proposal would record who burned an NFT

Filed on Ethereum Magicians on September 18, a new ERC-721 Burn Record Extension proposal asks one narrow question inside a running transaction: which address burned a specific token? The filing defines anIERC721BurnRecord interface and aburnedBy function, targeting a gap that existing burn and redemption standards leave open.

“A contract that has to decide something in the middle of a transaction cannot know who burned a token,” an ethereum-magicians.org user wrote in the discussion. Transfer logs can answer that question for off-chain systems. Contracts can’t read those logs as transaction inputs — so the information exists, just not where it’s needed.

Under the proposal’s rules,burnedBy(tokenId) returnsaddress(0) while a token still exists, and also returnsaddress(0) when no burn record is present. A token counts as burned only after it no longer exists and aTransfer event toaddress(0) has been emitted. Once a record is stored, the address it holds must equal thefrom field in that burnTransfer event.

That creates a standard read path for burn-linked rights. The discussion names a redemption flow where a claim belongs only to whoever burned the token, plus burn-to-mint flows and “destruction receipts.” The practical consequence is specific: a contract implementing this extension can make an in-transaction decision based on the burner’s address. Without that implementation, the information stays in event logs — queryable off-chain, invisible to the contract.

The proposal’s ERC-165 interface identifier is0x43470a89, giving consumers a way to detect support before calling. The zero-address return keeps the absence of a record technically distinct from a recorded nonzero burner, though only in one direction. A nonzero result is evidence of a stored burn record. Zero doesn’t tell you why no record exists.

That ambiguity matters for NFT positions and future marketplace logic — this desk’s read, not a claim in the filing. A consumer may still need to distinguish a token that was never minted from one burned before any record existed. The filing does not establish that the extension has been accepted, implemented or adopted by NFT contracts.

Four related standards get named as context. ERC-7634 exposes transfer counts throughtransferCountOf and emitsTransferCountIncreased; ERC-6672 exposes redemption state throughisRedeemed and emitsRedeem; ERC-5484 fixes burn permissions in advance; ERC-5679 standardises the burn operation itself. Two of the four — ERC-7634 and ERC-6672, exactly 50%, this article’s calculation — expose event-related state; the other two address permissions or mechanics. Unlike those four standards, this proposal records the burner address after the fact, on-chain, where contracts can read it.

A user in the discussion put the rationale this way: “The burner can of course be derived from Transfer events, and off-chain that is the right tool. Contracts have no access to it.” For off-chain marketplaces, this changes little immediately. For on-chain redemption, burn-to-mint, and receipt contracts, it determines which address is eligible at the exact moment a transaction executes.