Support superrare style offers

[bjartek]

One major issue for sellers of NFT is that if they price their assets to low and do not have time to update the price then some whale will come in and buy all their NFTs and relist for 2x or 10x the price.

In order to avoid this scenario I think it would make sense for this project to support superrare style offers That is, when an offer is accepted a timer is started for a given period (that could be specified in the sale offer). Until that timer runs out others can outbid the current offer and if they do the timer is reset. The seller can at any time chose to accept the current offer if he needs the funds right away.

In Versus we do something similar to this and it should not be to hard to implement.

I know many people are sceptical about keeping ft in escrow, but a very nice feature of this with blocto is that I always know when I a outbid.Since blocto will notify me on my cell when I get money transfered to me. (Btw beeing able to transfer money to somebody and leave a message would also be very nice)

[rheaplex]

Yes that makes sense. Is that something that could be built on top of the Storefront as a proxy resource and linked to /public/ instead of it, or should it be directly built in?

I think there are various scenarios in which we wouldn't want to start a timer, for example if the item has been on sale for a year and nobody has previously shown interest.

Immediate sales could be indicated by a zero second timer, and the purchase transaction could handle that eventuality. I'm wary about requiring two transactions rather than one to complete a sale, but in the zero timer case and others we can optimize things as much as possible.

[bjartek]

It could be directly built in I think, but it does require some work.

There are several other things to consider as well.

1. do you want to escrow latest bid or do you want to link to balancer that holds the funds.

2. if you want to esceow can you trust the storefront resource beeing in the sellers account or do you need a thirdparty trusted broker. (A user could sell something for a huge amount, you put in big esceow and they unlink. You are screwed)

3. if you do not escrow it kinda requires the seller to confirm the transaction when it has ended. (Since only the seller can transfer out ft)

I think that if you want to create a storefront with this kind of functionality it would make sense to set it up as a broker and allow users to add resources for sale to it, and then give them back a token that can admin that resource. But that might be a totally seperate project.

[bluesign]

Few comments:

This is basically bringing auction capability I guess, so it kinda needs escrow, but also then NFT should be in escrow too.

2 transactions issue is a bit of a problem. But it is only problem if you bid in first X minutes after listing. If X small, I think it will not make big difference.

[rheaplex]

Yes it's usually one transaction. The standard purchase transaction can be modified to handle both cases. The two transaction case looks like it needs a timer to provide a convenient user experience, but that shouldn't be onchain.

As for escrow, that's something I'd need to think through. 🤔

[bjartek]

Versus has the timer on chain and it has not been an issue for us. As long as you extend the duration on a new bid it is fair and works.

[rheaplex]

Oh I mean a cron-style timer. The timestamps should definitely be on chain, yes.

[bjartek]

Ah yes. For versus I have a script that runs ever 5mik that check for settled things. It will fire a transaction that settles if appropriate.

[rheaplex]

Yes that makes good sense for a platform. And it could be a paid service for users going through personal storefronts. But that's out of scope for this project. 🙂

[bjartek]

Fair enough.