epam / mintgate

1 stars 2 forks source link

F10: As an Owner I want list my Token on Mintgate marketplace #57

Closed zahhar closed 3 years ago

zahhar commented 3 years ago
  1. Owner is able to approve through NFT contract the Marketplace contract for one of owner Tokens.
  2. Owner sets the (minimum) price nominated in NEARs he wants to get for the Token if it is sold.
  3. Owner can have ONLY 1 Marketplace per Token approved simultaneously
  4. Batch approval (e.g. approve marketplace for all his Tokens nor all Tokens for GateID) is out of scope, see #62

As a result, Marketplace will know the following about the Token on sale: <TokenId, OwnerAccountId, MinPrice, NFTContractAccountId, CreatorAccountId, GateId>.

_NB! Marketplace WILL NOT know Token Metadata. To get TokenMetadata, one needs to get TokenId from Marketplace, and then call nfttoken() function on NFT contract.

Jshanks21 commented 3 years ago
  1. Correct
  2. Correct
  3. This is fine as long as our marketplace is able to de-list the item for sale if purchased on a second marketplace, so there is no item listed for sale when the item has actually already been purchased for that listing. Otherwise, how might this case be handled?
  4. It would be preferable if the Owner is able to approve a batch sell orders to avoid approving individual items one at a time if they want to sell multiple. For example, if the Owner wants to approve to sell 3 tokens of a specific GateId, or even series of different TokenIds they hold, that would be ideal. Perhaps for the GateId approach, just selecting the GateId and then an amount, and for the TokenId approach we could allow them to select from the TokenIds they currently own and each could be approved.

Happy to hear your feedback on points 3 and 4.

The rest seems fine.

zahhar commented 3 years ago

Thanks for reply, @Jshanks21

Regarding point 3: according to NEAR NFT standard, it's the Marketplace who is responsible to check if they are still approved by token owner to proceed with the sale. There is no (and won't be) a way to notify all other marketplaces if token was sold elsewhere, as such action would be just a waste of gas.

There are few options how this can be solved: (a) Disallow the Owner to list Tokens elsewhere then on Mintgate Marketplace. Anyhow it is Mintgate who exclusively owns both contracts: NFT + Marketplace. So you can set the rule that Mintgate NFTs can be sold only via Mintgate marketplace. (b) Allow Owner to approve only one Marketplace at a time per Token. In this case no conflict may occur: if user lists token elsewhere, then he needs to recall the approval for 3rd-party marketplace before listing token at Mintgate marketplace. Also vice-versa is true: first user would have to de-list token from Mintgate marketplace before he can try to sell elsewhere. ( c) Mintgate GUI checks time to time if its Marketplace contract is still approved by Owner for given Token. This can be done on-demand, as user browses the Marketplace (background ajax calls for items that are in the user's view but were not recently checked), or by scheduled job that runs every day or hour. (d) Be optimistic and assume that vast majority of users would never list their tokens elsewhere, or even if they list — they won't be successful and most sales will be facilitated by Mintgate marketplace. In this case no any checks are required. Just when a user is ready to buy, Mintgate marketplace will attempt to make a transfer, as if it fails because Marketplace contract is not approved anymore → then GUI says "Oops, sorry, seems this item has gone. But there are more..."

Do you have preferred option?

Regarding point 4: I will put batch approval as a feature request for Milestone 3. We can then prioritize in what order you would like us to build the remaining features, and we will produce as much as we can within the remaining sprint. As of now also NFT standard does not assume batch approval, but it is not a blocker to extend it in our contract, as it won't ruin compartibility with the standard.

before attempting to make a transaction. If market cannot, it should call itself to remove sale.

If market can make sale, it should try.

Purchase could still fail, market should clean up sale.

zahhar commented 3 years ago

Item 4 → #62 (for Milestone 3) created.

Jshanks21 commented 3 years ago

Great! Thank you for the clarification @zahhar.

Regarding point 3, I think option (b) would be the best option for us. We want users to be able to take their NFTs to any marketplace.

We want users to be able to take their NFTs to other markets if they desire, but ours should be the best option to reduce this likelihood. We don't want to lock them in by disallowing them to go elsewhere though.

Option (c) is viable but still requires approvals to be updated even after the check in order for the marketplace to be up to date. So there sounds like additional steps would be needed for this.

Option (d) is also viable, but not the best UX, and could be problematic if there's potentially a different error causing this and we end up assuming the NFT has been sold which is causing the error.

Regarding point 4, that sounds good.

jadbox commented 3 years ago

Hey @zahhar, it sounds like option B is the simpliest way to support multiple marketplaces. Is this a correct assumption?

zahhar commented 3 years ago

@jadbox @Jshanks21 - yepp, option (b) also looks for me as a helthy compromiss that won't break compatibility with the standard, also gives some reasonable tradeoffs: users still can trade elsewhere, and Mintgate will not need to compomise on UX or build an overcomplicated system to track edge-cases when someone sells token via multiply marketplaces.

Let's lock it and we will take option (b) into development in this Milestone.

zahhar commented 3 years ago

Then we will have to implement:

zahhar commented 3 years ago

WIP: