A NEP is a design document for providing information to the NEAR community or describing a new feature for the NEAR protocol or Smart Contract standards. The NEP should provide a concise technical specification and a rationale for the feature.
NEPs are intended to be the primary mechanism for proposing new features, coordinating formal feedback, and documenting design decisions that were integrated into NEAR’s runtime or Smart Contract ecosystem.
As such, the NEP’s author is responsible for building consensus within the community and documenting dissenting opinions.
Because NEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. A list of NEPs is available on GitHub.
NEP 819 is a standard for burning NFTs. It acts as an extension to NEP 171 and requires NEP 177 & 297.
Currently, there is no standard for minting and burning (NEP 171), but there is NEP 297 which handles NFT events (nft_mint, nft_transfer, and nft_burn). NEP 819 extents the core functionality of NFT contracts on NEAR Protocol by providing a standard for NFT burning as well as an on_burn helper function for burning “utility NFTS” (NFTs that are meant to be burned in exchange for a good or service).
NEAR Ecosystem NFTs are evolving from being unique records with a pointer to metadata into being real-world assets that can be interacted with for goods and services. The NFT standards should also evolve to more efficiently support developers as they build their projects.
Having a variety of methods for burning NFTs adds unnecessary complexity (this should be standardized). Having no standard for burning “utilty NFTs” makes it more difficult for NFT owners across the NEAR ecosystem to keep an efficient record of how they are using their NFTs.
While there are projects that handle burning NFTs at the application layer, which provides useful functionality for real-world use cases of NFTs (NFT tickets for example), there is no standard.
Handling non-utility NFT burns at the application layer solves the problem of needing to remove unwanted NFT data from future NEAR Protocol blocks but does not address the need for a “receipt” when an NFT owner decides to burn their utility NFT.
Provides two functions to support NFT burning
- allows an NFT owner to burn an NFT (assuming the token exists and the owner is actually the token owner)
- saves the metadata (to be used for the event emittion)
- burns the NFT with the same assumptions as the burn function
- derives the token_id for a new receipt NFT from the original burnt token
- mints a new NFT with the derived token_id and the metadata from the burnt NFT
NFT protocols would have to upgrade their contracts to add these burn features. This may cause initial confusion between protocols that apply this standard and those that do not.
What happens when two NFTs are burned in the same block? Without enumeration and in an async scenario
We believe that NEP 819 is the beginning of offering numerous on-chain flows upon burning. In the future, we would hope to extend the standard and build upon it to allow for more possibilities, such as:
- NFT evolution (wrap NFT in contract with counter. As counter > evolution value, utility_nft_burn)
- NFT receipts (ticketing, coupons, memberships)
- More efficient on-chain gaming with the ability for collaborative action
Nomicon NFT standards: Non-Fungible Tokens | NEAR Protocol Specification
Copyright and related rights waived via CC0.