OpenSea’s latest code snippet gives them the ability to entirely control which platform your NFTs can (or cannot) be traded on.
We propose to add basic marketplace functionality to the ERC721 standard to allow projects creators to gain back that control.
It includes:
~ a method to list an item for sale or update an existing listing, whether private sale (only to a specific address) or public (to anyone),
~ a method to delist an item that has previously been listed,
~ a method to purchase a listed item,
~ a method to view all items listed for sale, and
~ a method to view a specific listing.
This interface could also be adapted for ERC1155 standard, but might require adjustments
Edit:
This proposal is both compliant with OpenSea’s snippet and safe from it as it doesn’t need to make usage of the transfer(), safeTransfer(), and approve() functions.
This way, if OpenSea suddenly decided to completely block all other marketplaces, your internal marketplace can still operate.
Would also add to this that the code as presented is compliant with the new snippet from opensea for their listing function, but collection-only marketplaces will not be affected if OpenSea were to choose to do something nefarious, because (and why) this code doesn’t affect approval and transferFrom protocols.
It therefore also leaves the devteam/founders to decide what kind of secure control they wish to implement over those functions to increase security of their collections and specify which marketplaces can/should be aloud to carry out 3rd party trading.
Yes, the interface doesn’t really care about the currency used, so if you want to use a different currency than the default chain token, make sure you add the address of the currency contract in your code, and use appropriate transfer on those tokens
Will the listing and delisting functionality be the same as an Opensea or anywhere else, meaning you have to sign and also pay gas in order to switch it on and off? I assume yes but I am asking just in case you might have did some wizardry where its simpler (and cheaper)
To be clear, currently the purchase function is “payable” and thus is expecting an eth amount in our example code. However this is only the default listed idea. It could easily be modified with the same interface to allow payment via ERC20 token.
Other “purchase” functions can be added as needed to suit the intended functionality of your smart contract.
I’m not writing that part, lol. Hate interfacing with swap contracts, but this is totally doable. Great idea as an optional upgrade. Maybe something like this can be added to our example code on GIT when we are ready, or a fork could be made.
Gas is a thing, it’s always there, but there is no “setApprovalForAll()” required as you are interacting with the SC directly. The list and delist functions by themselves are quite small and easily manageable, gas costs should be minimal. Also listing again kills the previous listing, so if you want to change price or set so one wallet address only can purchase, it’s the same call to change the existing listing.
You’re good, discussion needs to be open and I’ve been doing some twitterspaces to discuss these issues.
I considered expiration, and agree it could be valuable, but left it out for simplicity. There is really nothing stopping someone from adding it to the base code that we are using for this standard. You would simply need to add some checks to the buy function as well as the data being pulled to your front end.
However, this extension does not solve the royalty issue. It is correct that “if the sale is not on the in-built marketplace, then royalty is not guaranteed” but this does not ensure that sale is only via inbuilt marketplace.
it doesn’t solve the entirety of the royalty issues, as long as you allow any marketplace to operate sales for you, but if you couple that with blocking transfer from 3rd parties, for example, then only your contract can handle sales, ensuring that all royalties are paid.
If the NFT project is willing, it can set up a blacklist function to prevent NFT from being traded on all intermediary trading markets that do not charge copyright taxes.
On the other hand, I am also considering the rationality of copyright tax. IMHO, the copyright tax charged by many NFTs is too high, but it does not bring enough benefits to NFT holders.
In addition, we have also considered some new copyright tax schemes to adapt to different categories of NFT.
But I’m sorry that I haven’t translated it into English yet, so I have to suggest you use Google Translate or DeepL to read it.