Idea: A marketplace extension to ERC721 standard

Thank you Lambdalf for posting this.

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.

1 Like

right, I’ll update the initial post to reflect it better

1 Like

Nice that this standard would work in tandem with EIP-2981: NFT Royalty Standard

Can the interfaces support sales in currencies other than ETH? e.g. I imagine a lot of projects would want to use their own utility token for sales.

1 Like

It wouldn’t be too hard for the purchase function to call uniswap and swap the ether for the correct number of tokens, and send back the excess.

1 Like

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

1 Like

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)

This implies the sale price is always pegged to ETH which they may not want. e.g. you might want to peg to USDC

This wouldn’t support multiple tokens when using the interface. Would we be able to sell one token for $APE and another for $ETH? for example

Think it would be valuable to include a deadline/expiry when listing an item for sale.

Sorry for multiple posts, I didn’t see the quote reply feature…

No, it doesn’t. Here is how it could work:

  1. I send 0.1 ETH to buy an NFT
  2. The marketplace calls uniswap to transform (for example) 0.0008 ETH into 1 USDC, leaving 0.0992 ETH.
  3. That 1 USDC gets sent to the NFT’s owner.
  4. The NFT is transferred.
  5. The remaining 0.0992 ETH gets sent back to the original caller.
1 Like

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.

Cryptopunks, that precede the ERC721 standard itself, seem to have this idea in right direction, incorporating this model. Have a look at cryptopunks/CryptoPunksMarket.sol at master · larvalabs/cryptopunks · GitHub

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.

That can be done via off-chain means (such as legal agreements).

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.

Here is some content, also can be used as a reference