ERC-721-voorstel wil vastleggen wie een NFT heeft verbrand

Op 18 september ingediend bij Ethereum Magicians, stelt een nieuw ERC-721 Burn Record Extension-voorstel één specifieke vraag binnen een lopende transactie: welk adres heeft een bepaald token verbrand? De indiening definieert eenIERC721BurnRecord-interface en eenburnedBy-functie, gericht op een hiaat dat bestaande burn- en inwisselingsstandaarden open laten.

“Een contract dat halverwege een transactie iets moet beslissen, kan niet weten wie een token heeft verbrand,” schreef een gebruiker van ethereum-magicians.org in de discussie. Transfer-logs kunnen die vraag beantwoorden voor off-chain systemen. Contracten kunnen die logs niet lezen als transactie-inputs — de informatie bestaat dus wel, alleen niet op de plek waar ze nodig is.

Volgens de regels van het voorstel geeftburnedBy(tokenId)address(0) terug zolang een token nog bestaat, en ookaddress(0) wanneer er geen burn-record aanwezig is. Een token telt pas als verbrand nadat het niet meer bestaat en er eenTransfer-event naaraddress(0) is uitgezonden. Zodra een record is opgeslagen, moet het adres dat daarin staat overeenkomen met hetfrom-veld in dat burn-Transfer-event.

Dat creëert een standaard leespad voor aan burns gekoppelde rechten. De discussie noemt een inwisselingsflow waarbij een claim alleen toebehoort aan wie het token heeft verbrand, plus burn-to-mint-flows en “vernietigingsbewijzen.” De praktische consequentie is concreet: een contract dat deze extensie implementeert, kan binnen een transactie een beslissing nemen op basis van het adres van de verbrander. Zonder die implementatie blijft die informatie in event-logs staan — off-chain opvraagbaar, maar onzichtbaar voor het contract.

De ERC-165-interface-identifier van het voorstel is0x43470a89, waarmee afnemers kunnen controleren of ondersteuning aanwezig is voordat ze de functie aanroepen. De terugkoppeling van het nul-adres houdt de afwezigheid van een record technisch onderscheiden van een geregistreerde, niet-nul verbrander, al geldt dat maar in één richting. Een niet-nul resultaat is bewijs van een opgeslagen burn-record. Nul vertelt je niet waarom er geen record bestaat.

Die dubbelzinnigheid is relevant voor NFT-posities en toekomstige marketplace-logica — dit is de duiding van deze redactie, geen bewering uit het voorstel zelf. Een afnemer moet mogelijk nog altijd onderscheid maken tussen een token dat nooit is geminet en een token dat is verbrand voordat er enig record bestond. Het voorstel stelt niet vast dat de extensie is geaccepteerd, geïmplementeerd of overgenomen door NFT-contracten.

Vier verwante standaarden worden als context genoemd. ERC-7634 toont transferaantallen viatransferCountOf en zendtTransferCountIncreased uit; ERC-6672 toont inwisselingsstatus viaisRedeemed en zendtRedeem uit; ERC-5484 legt burn-rechten vooraf vast; ERC-5679 standaardiseert de burn-handeling zelf. Twee van de vier — ERC-7634 en ERC-6672, precies 50%, een berekening van dit artikel — tonen event-gerelateerde status; de andere twee betreffen rechten of mechaniek. In tegenstelling tot die vier standaarden legt dit voorstel het adres van de verbrander achteraf vast, on-chain, waar contracten het kunnen lezen.

Een gebruiker in de discussie verwoordde de onderbouwing zo: “De verbrander kan natuurlijk worden afgeleid uit Transfer-events, en off-chain is dat het juiste middel. Contracten hebben daar geen toegang toe.” Voor off-chain marketplaces verandert dit voorlopig weinig. Voor on-chain inwisselings-, burn-to-mint- en bewijscontracten bepaalt het welk adres precies op het moment dat een transactie wordt uitgevoerd in aanmerking komt.