A brief description of ERC721R: Mom no longer has to worry about my NFT being broken
Today, a new NFT token standard called "ERC721R" was officially released. This function adds a trustless refund function to the smart contract of NFT, allowing minters to freely "return" within a certain period of time.
Specifically, the NFT that adopts the ERC721R standard will set a refund period of a specific length of time (set by the project party, for example, one month) at the time of issuance. During this period, the fees paid by the user to cast the NFT It will be hosted in the smart contract. Before the end of the refund cycle, the project party has no right to withdraw funds from the smart contract. Users (and buyers in the secondary market) can choose to return the NFT within this cycle and return the NFT to the project Party, and at the same time get back the corresponding casting fee (excluding gas fee).
In the introduction of ERC721R, the developers of this standard emphasized such a sentence - "The NFT space needs a stronger sense of responsibility.”
For the project side, the integration of ERC721R will be an excellent opportunity to show their sense of responsibility. They need to prove their development capabilities to the buyer's market within the refund cycle and prove that "our products are worth this price".
For users and buyers in the secondary market, ERC721R can be understood as a new dimension for screening projects in a sense, and it can also be regarded as a good "regret medicine". Compared with NFTs that do not integrate this standard, the protected casting price of ERC721R is obviously more attractive. When faced with some projects with short-term casting volume or rapid growth in trading volume, users can even cast or buy first, pending further investigation Then decide whether to hold or refund.
Considering that some NFTs may require casting fees to maintain project operations, ERC721R also supports the project side to make some fine-tuning in specific implementation, such as only locking 90% of funds, or only supporting the first 90% of users to initiate a full refund payment. However, the developers of ERC721R believe that this situation may be rare, because since the project party can issue NFT without funds, it means that their demand for funds will not be too emphasized.
PortalPortal” to submit intent to integrate with the standard.
On the whole, the design of ERC721R is directed at the very common "break" problem in the NFT field (especially in the pfp field).
As the popularity of NFT has risen rapidly in the past year, the market has long been mixed, filled with a large number of shoddy or even purely fraudulent projects. In the past period of time, there have been some other projects trying to solve the NFT breaking problem through various efforts (such as the DeFi token backing made by HOURAI), but considering the popularity potential, ERC721R is obviously a qualitative breakthrough. Projects with absolute confidence in their own future development only need simple integration to dispel users' worries about "breaking".
From the ERC721A launched by the Azuki team to today's ERC721R, we see that more and more developers are providing effective solutions to one problem after another in the NFT field. This may be the most sustainable development of the NFT industry. Let's prove it.
----------Dividing line----------
Update at 17:30 on April 12:
Ben, the core developer of GoPocket, tweeted that there is a serious bug in the ERC721R code segment. Due to the lack of restrictions on the refund receiving address, the developer can use the bug to withdraw the funds in the contract during the refund cycle, thereby bypassing the agreement. Constraint, implements RugPull.
Ben said that under normal circumstances, after the refundEndTime unlock expires, the NFT developer calls the withdraw() function to take away the raised ETH, and there is no problem with this step. The problem lies in the refund refund() function: after the NFT buyer calls refund(), he will transfer the NFT he minted to the refundAddress (the address is specified and controlled by the developer), and then get the corresponding amount from the NFT contract. ETH, but what if refundAddress itself mints NFT? The scammer project party can set a refundAddress, and then use this address to mint an NFT. In the next step, he directly calls the refund function refund(), because all NFTs will be refunded to this refundAddress, so he still holds some ETH while getting some ETH. With this NFT, he can keep calling refund() to empty out the money in the contract.
Ben believes that this bug directly makes ERC721R useless, and developers can still run away with money, and it is hidden deeper under this "seven-day no-reason return narrative". New NFT projects should not directly use other NFT projects before ERC721R is updated. code.
----------Dividing line----------
This news is still being updated, and the progress of the standard and bugs will continue to be added to the article.
