More and more NFT issuers such as artists, fine art galeries, auction houses, brands and others want to offer a physical object to the holder of a given NFT. As of now, one can’t link a physical object to an NFT.
We’d like to make a standard proposal we’ve been working on. It’s called Redeemable and it’s a standardized way to link a physical object to an NFT.
The Redeemable NFT Extension adds a redeem function to the ERC-721. It can be implemented when an NFT issuer wants his/her NFT to be redeemed for a physical object.
If you want to get something standardized you should start by explaining de motivation. What is currently not working ? Explain the previous work is, and what it fails at doing. You should then carefully describe the interface, and the usage workflow, to show that it actually solves the issues you identified.
Thank you very much for your reply. It’s appreciated!
I agree but it shouldn’t be too ‘restrictive’ though: for instance if we name it redeemPhysicalObject(), people could think that’s the only covered use case, whereas it also can be used to redeem anything (including on-chain assets, tickets, …). We wanted to keep it a bit general.
Right now if you sell an NFT that’s redeemable for a physical object, you would declare it in the description but there’s no way to verify if the object was already redeemed or not.
Also, a marketplace can verify if the NFT is redeemable or not, and also verify if it was already redeemed or not. After the redeem() function is triggered, the marketplace sends the buyer’s physical address to the seller.
My proposal is focused on securing the redeeming part: how to allow your target user to redeem the token while avoiding anyone else to redeem it. I don’t understand how to do that on a EIP-5560 contract.
To make a redeeming secure with a EIP-5560 contract, do I have to pre-assign the token to the right account?
To be honest, I’m trying to understand if we are working on the same thing (if yes I will try to adapt my code to use this EIP) or if we have distinct goals (if so, maybe we both should use a less ambiguous name )
No worries, I will give some feedback on your proposal. The targeted use cases seem to be pretty different from each others. You basically want to send some value to someone that doesn’t have a wallet address, and we want to allow an NFT holder to redeem a physical object (artworks, tickets, …).
Our proposal works with ERC-721 only. We don’t need to pre-assign anything because the NFT holder address is already known (already minted).
Two different projects with distinct goals here.
Like @Amxx mentioned before, the naming might be problematic for both of us.
I think redeem() as a function name is acceptable in our two cases.
Hi everybody!
I m amazed by your EIP-5560, and looking forward to use the redeem function in our project. Having figured out that “it also can be used to redeem anything (including on-chain assets, tickets, …)” including ERC-20 Token, I would suggest. " RedeemAsset " as no-conflictive name!
).
)
