Add market-making to the Distributed Exchange spec

[ripper234]

Market making charges a fee from people making Market orders, and transfers that fee to people making Limit orders. This way people are incentived to keep the order full.

The idea to add this followed a discussion we had with Yoni Assia from eToro, and seeing CoinMKT implement this.

However, I am not confident that this makes sense in our system. It makes sense in a system where a limit order is atomically counted as either a NEW limit order or matching an EXISTING limit order. In such a system the reward is received when the atomicity condition is fullfilled, and the system decided if an order is NEW or fills an EXISTING order.

In the Master Protocol, (if I'm not mistaken in my interpretation), there isn't really a built-in order matching engine - rather, the client needs to decide whether it tries to match an existing order, or place a new one. So instead of adding such a fee, any client that decides to place a new order, can just price in the market making fee.

So - in my understanding - I am not sure there really is a place for such a feature. Leaving the issue here for discussion, if I don't see convincing arguments in favor then I'll close the issue.

[dacoinminster]

I actually really like this idea. Sure, people won't always know if they are placing a market order or a limit order, but it will still encourage limit orders, which I think is great.

[dacoinminster]

Also, note that this does not affect the current MSC/BTC exchange, only exchanges between mastercoin and mastercoin-derived currencies (where there are both bids and asks)

[ripper234]

@dacoinminster - my point is that since in the current Mastercoin spec, unlike a centralized exchange, you always know in advance if you are placing a limit order - then you can just increase your price a bit. I don't see a real advantage to us enforcing this at the protocol level with a constant magic number.

This is unlike a centralized exchange where you just can't know in advance whether your order turns out to be a market or limit order when you place a limit order, so you cannot adjust your price accordingly.

[dacoinminster]

I think centralized exchanges treat a limit order which would be executed instantly as a market order (and you pay a fee) so they have the same issue, although on a much smaller timescale.

I really think incentivizing people to put their coins for sale (rather than executing on the best available price already for sale) is very good for our ecosystem.

On Wed, Jan 29, 2014 at 1:32 PM, Ron Gross notifications@github.com wrote:

@dacoinminster https://github.com/dacoinminster - my point is that since in the current Mastercoin spec, unlike a centralized exchange, you always know in advance if you are placing a limit order - then you can just increase your price a bit. I don't see a real advantage to us enforcing this at the protocol level with a constant magic number.

This is unlike a centralized exchange where you just can't know in advance whether your order turns out to be a market or limit order when you place a limit order, so you cannot adjust your price accordingly.

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/44#issuecomment-33633231 .

[DavidAJohnston]

I say we tap a few folks with exchange experience to weigh in on this topic. Could be a long term discussion no need to rush to conclusion on either side. Let's gather thoughtful opinions and expertise from those that have faced this question in other contexts.

[taariq]

Dmitry has the substantial exchange IT expertise. I¹ve cc¹d him on this note.

From: David Johnston notifications@github.com Reply-To: mastercoin-MSC/spec <reply+i-26554184-2e80723fb02f1bbb0198415be2f7813e6ab8fc96-701864@reply.gith ub.com> Date: Wednesday, January 29, 2014 at 3:49 PM To: mastercoin-MSC/spec spec@noreply.github.com Subject: Re: [spec] Add market-making to the Distributed Exchange spec (#44)

I say we tap a few folks with exchange experience to weigh in on this topic. Could be a long term discussion no need to rush to conclusion on either side. Let's gather thoughtful opinions and expertise from those that have faced this question in other contexts.

‹ Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/44#issuecomment-33645712 .

[ripper234]

Now that I think about it - I just want to get something straight - @dacoinminster maybe you can help me understand the current spec:

If there is an offer to SELL 10 MSC at 0.1 BTC per MSC, and someone then boardcasts an offer to BUY 10 MSC at 0.2 BTC per MSC - do these offers "fulfill each other automatically"? Perhaps the current spec doesn't support this use case, but it should, and it might be a relatively easy change. My expectation from the above case that the later BUY order would be converted into a market order.

Note that if we don't support this use case automatically, then our exchange would have very weird interleaving bid/ask bid/ask charts and open up weird arbitrage play.

If this usecase is supported by the current spec, or the spec can be modified to include it, then it makes perfect sense to me to award the first order with a small margin. I generally don't like magic numbers so I would prefer the offer itself to contain this margin as a parameter.

[dacoinminster]

Yeah, orders which match are automatically filled under the current spec. The second one processed (even if they were in the same block) would be considered the market order.

Most real-world exchanges use a set number like 0.25%. Yes, that isn't as flexible, but from a useability perspective, that's one less thing the user has to think about when creating an order if we just set it to something reasonable. Also, it's easier to code.

On Thu, Jan 30, 2014 at 7:13 AM, Ron Gross notifications@github.com wrote:

Now that I think about it - I just want to get something straight - @dacoinminster https://github.com/dacoinminster maybe you can help me understand the current spec:

If there is an offer to SELL 10 MSC at 0.1 BTC per MSC, and someone then boardcasts an offer to BUY 10 MSC at 0.2 BTC per MSC - do these offers "fulfill each other automatically"? Perhaps the current spec doesn't support this use case, but it should, and it might be a relatively easy change. My expectation from the above case that the later BUY order would be converted into a market order.

Note that if we don't support this use case automatically, then our exchange would have very weird interleaving bid/ask bid/ask charts and open up weird arbitrage play.

If this usecase is supported by the current spec, or the spec can be modified to include it, then it makes perfect sense to me to award the first order with a small margin. I generally don't like magic numbers so I would prefer the offer itself to contain this margin as a parameter.

Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/44#issuecomment-33696454 .

[ripper234]

Ah I see. In this case it makes perfect sense to add this.

I don't think this makes such a difference for usability - the protocol could support a varying percent even if some client interfaces don't expose this. In any case the client will need to take this percent into consideration when processing Market Orders (clients need to know where this percentage goes).

Ron Gross Executive Director, Mastercoin Foundation mastercoin.org | ripper234.com | ripper234 on skype (Inbox non Zero http://ripper234.com/p/how-i-learned-to-let-go-of-inbox-zero/) Schedule my time at meetme.so/RonGross

On Thu, Jan 30, 2014 at 8:50 PM, dacoinminster notifications@github.comwrote:

Yeah, orders which match are automatically filled under the current spec. The second one processed (even if they were in the same block) would be considered the market order.

Most real-world exchanges use a set number like 0.25%. Yes, that isn't as flexible, but from a useability perspective, that's one less thing the user has to think about when creating an order if we just set it to something reasonable. Also, it's easier to code.

On Thu, Jan 30, 2014 at 7:13 AM, Ron Gross notifications@github.com wrote:

Now that I think about it - I just want to get something straight - @dacoinminster https://github.com/dacoinminster maybe you can help me understand the current spec:

If there is an offer to SELL 10 MSC at 0.1 BTC per MSC, and someone then boardcasts an offer to BUY 10 MSC at 0.2 BTC per MSC - do these offers "fulfill each other automatically"? Perhaps the current spec doesn't support this use case, but it should, and it might be a relatively easy change. My expectation from the above case that the later BUY order would be converted into a market order.

Note that if we don't support this use case automatically, then our exchange would have very weird interleaving bid/ask bid/ask charts and open up weird arbitrage play.

If this usecase is supported by the current spec, or the spec can be modified to include it, then it makes perfect sense to me to award the first order with a small margin. I generally don't like magic numbers so I would prefer the offer itself to contain this margin as a parameter.

Reply to this email directly or view it on GitHub< https://github.com/mastercoin-MSC/spec/issues/44#issuecomment-33696454>

.

— Reply to this email directly or view it on GitHubhttps://github.com/mastercoin-MSC/spec/issues/44#issuecomment-33719640 .

[dacoinminster]

I think it is high priority to get this into the spec in time for the meta-dex work. I changed the labels and milestone accordingly.

[patrickdugan]

I would like to do a draft. This is something we'll be programming for directly later this month or early next month.

[marv-engine]

@ripper234 Just to clarify from your example,

If there is an offer to SELL 10 MSC at 0.1 BTC per MSC, and someone then boardcasts an offer to BUY 10 MSC at 0.2 BTC per MSC

tx20 Sell Mastercoins for Bitcoins is used to post an offer to sell MSC for BTC. tx22 Purchase Mastercoins with Bitcoins is used to accept a specific sell offer, which requires the purchaser to then send BTC to the seller within the specified number of blocks.

The upcoming tx21 Sell Master Protocol Coins for Another Master Protocol Currency will do the automatic matching and fulfillment, but it's not for BTC. Note that the current description in the spec is not up-to-date.

There is no transaction to post a generic offer to buy MSC for BTC.

[dacoinminster]

@patrickdugan Sounds great! It might only take a couple sentences. If you get into multiple paragraphs, that's too much ;)

As a starting point, I'd suggest a 0.3% fee which goes to the earlier order when two orders are matched using TX21.

[marv-engine]

@dacoinminster said (today in an email):

When matching orders, 0.3% fee should be charged to the buyer (new order) and given to the seller (older order). This incentivizes liquidity (it's better to be the older order). See issue #44.

The mechanics of this should probably just be to deduct 0.3% from what the seller has to send to the buyer once all other matching logic is complete. Fee should be rounded to nearest number which can be represented (which means sometimes the fee could be as high as 0.6%, or as low as 0%.

Some people might try to create small orders to avoid this fee, but generally the bitcoin transaction expense will prevent that from happening too often.

So for existing orders, that's 1 token withheld for every 333.33 tokens sold, with the number of indiv tokens rounded up or down to the nearest whole number. The order placement UI and the order history UI have to provide info about this fee.

[dexX7]

Maybe I didn't grasp the full idea behind this, but enforcing a one-sided fee which is credited to the other side seems pretty useless to me since this is predictable and any buyer/seller can simply adjust the price accordingly. Being buyer or seller in DEx context is also just a matter of perspective -- more or less. ("Do I buy BTC or do I sell MSC?")

Edit: I did read the CoinMK announcement and I'd love to read how this could be done here in detail.

[dacoinminster]

@dexX7 Big exchanges do this for a reason. Basically, it provides a disincentive to "market" orders (which remove liquidity). It provides an incentive to anybody using the dEX to add liquidity rather than remove it.

[taariq]

+1 and yes. It reduces spreads which is super duper helpful to creating an even market.

[ripper234]

As we're gearing up to work on the Metadex exchange, I think it makes a lot of sense to introduce this. See also #187 where we will decide on the MVP of the Metadex. I would very much like this feature to be included in the first drop if possible - I think it will add natural liquidity.

[dacoinminster]

Yup, Marv is putting this liquidity bonus/fee into the first rev :)

On Tue, Jun 3, 2014 at 7:16 AM, Ron Gross notifications@github.com wrote:

As we're gearing up to work on the Metadex exchange, I think it makes a lot of sense to introduce this. See also #187 https://github.com/mastercoin-MSC/spec/issues/187 where we will decide on the MVP of the Metadex. I would very much like this feature to be included in the first drop if possible - I think it will add natural liquidity.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/44#issuecomment-44969738.

[ripper234]

Sweet On Jun 6, 2014 1:43 AM, "dacoinminster" notifications@github.com wrote:

Yup, Marv is putting this liquidity bonus/fee into the first rev :)

On Tue, Jun 3, 2014 at 7:16 AM, Ron Gross notifications@github.com wrote:

As we're gearing up to work on the Metadex exchange, I think it makes a lot of sense to introduce this. See also #187 https://github.com/mastercoin-MSC/spec/issues/187 where we will decide on the MVP of the Metadex. I would very much like this feature to be included in the first drop if possible - I think it will add natural liquidity.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/44#issuecomment-44969738.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/44#issuecomment-45284569.