WIP: CEP-82: Trading Extension to CEP-78 #82
Conversation
| ### Duration | ||
|
|
||
| Another dimension that can differentiate `Marketplace` contracts is _duration_: | ||
| * A `Marketplace` can be _instant_, meaning that an exchange of items can happen as soon as two parties agree, such as in a swap. A consequence of this is that only the _seller_ needs to hand over custody of the item being sold, whereas the _buyer_ operation can be atomic. `CustodyApproval` will suffice for this `Marketplace` |
There was a problem hiding this comment.
If I'm reading this correctly, then with only CustodyApproval I think there is potential for the order book to become out of sync if the NFT owner directly transfers the item while it is listed, which has several ramifications depending on the order book implementation.
There was a problem hiding this comment.
This is true. To be fair, I'm struggling to find a use case where using the approve mechanism would make sense.
Though in a very simplistic implementation, the offending item could simply be removed upon trying to purchase it.
There was a problem hiding this comment.
Yes but doesn't lead to the best market UX - user tries to buy, the transaction fails, they get charged a fee & find out the item isn't actually for sale 😓
Also for 3rd party dapps & services they would not have access to a correct orderbook while items are incorrectly listed. Assuming there will be an orderbook index to access.
| * `DurationInstant` | ||
| * `DurationContinuous` | ||
|
|
||
| ### Interface / Key Functions |
There was a problem hiding this comment.
We need to clearly disambiguate these entry point names because they will collide with the entry points on the systems auction contract, something like "post_marketplace", "bid_on_nft"
|
Hi - please close this PR if the standard is complete and approved. Thanks |
|
@gRoussac please take a look |
rendered