Sequential Swaps

[cryptoquick]

In BMC, we'll need to support 3 kinds of swaps so far:

• P2P swaps
• Auction swaps
• Sequential swaps

Only P2P swaps make sense with RGB20, the rest are for RGB21.

Due to how RGB works, if an issuer wants to sell multiple items in a collection, they'll need to create a new UTXO, and then assign the token change to a new witness UTXO. So, items can only be sold sequentially, not out of order, since the change needs to go to a new UTXO.

Later if a specific RGB21 asset is desired, they can be put up for sale by individuals in auction swaps or P2P swaps on their own UTXOs.

Multiple bids can be made on a sequential swap, and the highest will be chosen by the auction coordinator. Unfortunately we have no opportunity for Vickrey auctions due to the PSBTs for bids being signed in advance.

We'll need to be able to provide a Vec of IssueRequests. These will be encrypted to Carbonado by bitmaskd as offers, preferably in separate files so sold asset files can be removed. These are then used to satisfy bids by bitmaskd as a coordinator.

We will also need the capability to specify multiple fee recipients.

[crisdut]

In BMC, we'll need to support 3 kinds of swaps so far:

• P2P swaps
• Auction swaps
• Sequential swaps

Who defines the strategy is the creator of the offer?

if an issuer wants to sell multiple items in a collection, they'll need to create a new UTXO

How do we define collections in the marketplace?

We'll need to be able to provide a Vec of IssueRequests. These will be encrypted to Carbonado by bitmaskd as offers, preferably in separate files so sold asset files can be removed. These are then used to satisfy bids by bitmaskd as a coordinator.

I don't understand this part.

We will also need the capability to specify multiple fee recipients.

It will be the BMC that defines this, not the users, correct?

[cryptoquick]

In BMC, we'll need to support 3 kinds of swaps so far:

• P2P swaps
• Auction swaps
• Sequential swaps

Who defines the strategy is the creator of the offer?

They're all completely different methods, called by the offer creator, correct. P2P swaps might be more complex since they should work without a coordinator, and we'll also need to differentiate between RGB-RGB swaps and RGB-BTC swaps.

if an issuer wants to sell multiple items in a collection, they'll need to create a new UTXO

How do we define collections in the marketplace?

They'll be provided as an Vec of IssueRequests.

We'll need to be able to provide a Vec of IssueRequests. These will be encrypted to Carbonado by bitmaskd as offers, preferably in separate files so sold asset files can be removed. These are then used to satisfy bids by bitmaskd as a coordinator.

This is similar to how you implemented swaps earlier, you'll be able to reuse much of the same stuff, just with a few more loops / iterables. :)

We will also need the capability to specify multiple fee recipients.

It will be the BMC that defines this, not the users, correct?

It will be BME that defines this, from data it gets from our databases and things we set. I'd actually prefer them not to be constants, but passed as arguments to methods by an external caller.