A few days ago, I discussed with you the existing problems of NFT. Among them, I mentioned that buyers are in a weak position in the NFT market. They are manipulated by the project side in the primary market, and the secondary market depends on the project side to do things rather than run away with money, and deduced an ideal model
At that time, the model promoted was the mint process of the primary market. To ensure absolute fairness, the secondary market needed to let the project party ensure that the money it got really cashed in the roadmap instead of cutting leeks. Therefore, first of all, the project party could not withdraw the money after the mint directly. After all, there are assets worth tens of millions on the account, and it only needs to move your fingers to mention the personal account. This temptation is hard to resist, Secondly, the withdrawal of the project party needs to be used in the right way, that is, to realize the commitment in roadmap. We should know that what the user spends money to buy is not the JPG of the project party, but the rights and interests and story after the jpg. At the moment of purchase, the user overdraw the future time of the project party.
I think the NFT market should be a market where good money drives out bad money. If the above model is implemented, if the project party does not use it, the user will think that the project party is guilty and will not buy it, and then force the project party to use a healthier model, and finally form a positive cycle to purify the whole market.
Today, someone in the group mentioned a new erc721r protocol, which is a bit like what we talked about above, so let's analyze what it realizes and how it is realized.
We can see media reports that it allows the foundry to refund.
We open the official website of erc721r https://erc721r.org/ , we can see that its slogen brings a great sense of responsibility to the NFT creator, so it restricts the rights of the project party and requires the project party to do things seriously, otherwise the user will take back the money in your pocket.
It can be seen that the four advantages listed by them are also focused on the problem of the project side running. If the project side does not do anything within 30 days, it can be refunded.
QA mentioned that the project side could not withdraw the mint funds during the refund period. Secondly, he also explained to the project side that if you were a serious project side, you certainly wouldn't need to withdraw the money immediately after the mint, so it doesn't matter to put it for a few days. The implication is that you don't need my agreement, that is, there are ghosts in your heart, and good money expels bad money.
The concept is very good. Next, let's take a look at how their code implements the above process. We go to their GitHub home page https://github.com/exo-digital-labs/ERC721R
You can see a more detailed description. It is said that the refund function is added to the original 721 and 1155 protocols.
For the description of the working principle, the money paid by the user first arrives at the smart contract (721 and 1155 itself), and then there is a lock-in period. During this period, the project party cannot withdraw money, but the user can refund it.
This is its sample code. Let me take you to disassemble it.
First, the lock period refundperiod is defined and defaults to 45 days. Of course, the project party can change it by itself.
Then the constructor is defined, and the default withdrawal account is the contract deployer,
A time calculation function is called, that is, to obtain the deployment time of the current contract and lock it regularly is the date when the final project party can withdraw money.
This function is used to check whether it is in the lock period, which will be used in the user refund operation below.
Then let's take a look at the core refund operation. The user enters the corresponding token ID to be refunded, because it is in the array format. Multiple NFTs can be refunded. Then, the contract first uses the verification function just mentioned to determine whether it is in the locking period. If it is, the user can refund from it, and then uses the for loop to traverse the token ID entered by the user and verify whether it really belongs to the current user one by one, If it belongs to, call the transfer function to return the user's NFT to the project party. Then calculate how much money should be returned to the user, that is, the number of NFTs returned by the user multiplied by the mint price, and then call the sendvalue of the third-party contract to call the user.
This is a normal withdrawal function of the project side. A check is added here to check whether the locking time is reached. If it is not reached, the function cannot be executed,
To sum up, the main changes of 721r to 721, 1155 and other protocols are as follows:
The withdrawal function adds an additional layer of time verification, and the withdrawal cannot be made before the time, thus limiting the project party
Added a function to refund users.
The whole process code amount does not exceed 30 lines. Secondly, it is not encapsulated at the bottom like 721a, and it is only modified in the mint contract code at the top. Therefore, it is determined first: it does not belong to the protocol or it does not reach the protocol level.
Secondly, because they are all changed in the upper-level contract, they will address the symptoms rather than the root causes, not to mention whether the project party will remove some restrictions. Of course, when you go to open source, you will also be seen through by everyone, but have you found a vulnerability here?
I still remember that in the refund mentioned above, the money returned to the user is the number of NFTs multiplied by the mint price, but the mint price is a parameter. As long as it is a parameter, it can be changed. If my price at Mint is 1eth and the project party changes the price to 0eth after mint, then I'm lonely And this process will not be found before the user refunds.
So let's run the code and see if this is feasible.
I set the price to 1eth and then Mint 5.
At this time, my balance is 94.99 (the initial 100 of the test network)
Then I will refund the NFT with ID 1.
After the execution, my balance has increased 1eth.
So at this time, suppose that I, as a project party who knows moral corruption and only wants to cut leeks, I must find a way to do some damage, right? I change the price to 0 and I'll let you return it.
Then I'll try returning the NFT with ID 2.
NFT is refunded, but the balance has not changed
Therefore, if you want to solve this problem, it also depends on the consciousness of the project party. Don't change the price, or write the price as a constant, which can't be changed at all. Don't rush as soon as you hear that the project party uses erc721r, or take a serious look at the code to see if there is any cheating you.
To sum up, erc721r is a clear stream in today's NFT market. He pointed out the disadvantages of this market, really considered it from the perspective of users, and put forward a practical solution. However, this solution is not so perfect, and there are still a lot of places that need to be improved and supplemented, but this does not prevent him from becoming a person who dares to tell the truth in this market.