Re: Limit and Market orders in COMIT

[Franck Royer]

On Thu, 3 Sep 2020 at 18:17, Daniel Karzel <dan...@coblox.tech> wrote:

Hi team,

during the course of the Tantalus project we had quite some thoughts on what it means to build a decentralised market, and market concepts ("trading" if you will) in general.

In this post I want to share thoughts on different kinds of orders and what they mean for doing swaps - i.e. decentral settlement of orders.
I want to share domain knowledge, learn more myself and align our brain model.

It would be cool if we can share these thoughts / model with people that have more domain knowledge (e.g. Toby) to find flaws early and not get stuck in a "wrong" model.
I generally think that we still have a lack of domain knowledge and would like to reach out to more experienced people for learning sessions. Happy for advice on that matter. (My current strategy is to trade more myself so I learn more while doing.)

I am planning to create another Basecamp post that can serve as another "glossary" entry after some discussion / alignment here.
I see this as information that does not change once agreed upon, but helps us keep the model together.

---

Introduction to Limit Order and Market Order:

Limit Order and Market Order are general financial terms outside the crypto world.

Forex Order Model Recap: https://3.basecamp.com/4403044/buckets/15109376/messages/2878398232
This model describes a Limit Order.

The Limit Order:

A Limit Order is an order where we specify a price limit.
The order will only be matched once the price reaches the specified limit.
Limit orders are publicly available (i.e. visible) in the market directly after creation.
A limit order does not necessarily settle at exactly the price specified. It settles at at least the specified price (i.e. it can settle at a better price).

So at the moment, we kind of have limit orders but they are more restricted:

- We only match exact price, not exact price or better

- We only match exact quantity. Limit order could be partially settled, matching with several smaller order

This makes me think that we should review and aim to make our order actual limit orders.

The Market Order:

The market order (or "best" order, or "best price" order) is an order that does not specify a price.
It only specifies a quantity that we want to buy/sell.
The best market price is selected automatically for you when publishing such an order.

Effectively this means:
When publishing a sell market order the best price is determined as the highest buy price currently on the market.
When publishing a buy market order the best price is determined as lowest sell price currently on the market.

This kind of matches our "best" button order.

In our case, we kind of place a limit order (see above) with the best price. The difference with a proper market order is that if someone else takes the best price before us then

no execution happens. Whereas on a central exchange, it will continue to execute the order (and tell you the price afterwards).

I think this feature is hard to implement on a DexOB. However, being able to place proper limit order at a best price could be a nice replacement in the short/medium term.

If we want to do a proper market order then I would expect the following flow (taking in account our current design).

1. User choose quantity to sell/buy and click "market order". Let's say buy 5BTC

2. Ambrosia looks at current order book,  see a 2 BTC limit order at $10,000 and a 4BTC limit order at $11,000.

3. Ambrosia broadcast a 2BTC limit order at $10,000 and a 3BTC limit order at $11,000

4. The other party sees the 2BTC limit order, it then gets fully executed

5. The other(other) party see the 3BTC limit order, it gets fully executed. The other party's order (4BTC) is only partially executed.

6. Ambrosia report back to the user and says that the market price for those 5BTC where (2 * 10,000  + 3 * 11,000)/5= $10,600.

Note that some market places implement more elaborate orders like stop orders (also called stop-limit orders), that take into account when a limit order becomes publicly visible [1].

Some more thoughts on orders:

As far as my understand goes, market orders are important for bringing trading volume into a market, i.e. how much quantity of a currency is traded during a time interval.

It's more that makers create limit orders and "market orders" are the easiest order to use. You don't try to predict a price, or plan in advance. You just want to sell/buy now at the current price. It's the "simplest" way to trade.

But again, being able to place a proper limit order at the current best rate is a good way to have pseudo-market orders on the DexOB.

If there is only limit orders in a market, and both sides don't move the market is "stale", i.e. no orders get executed.

True, until someone replace a limit order with another one that is executable.

Excursus:

Bid: The current best buy price. I think that eventually we will have to weight this by volume, because the price is bound to a certain quantity at that price.

This is not a feature available on the exchanges I am familiar with. Can you define "current best buy" using trading terms? Are you talking about limit order at best price? If so, then yes of course if the quantity of your order is bigger than

the quantity of the best price limit order on the trading book, then your limit order will not execute completely. That is something that is expected on a CEX so I don't think we should get out our way and make something better.

Ask: The current best sell price. I think that eventually we will have to weight this by volume, because the price is bound to a certain quantity at that price. 

---

This section goes more into detail of orders and swaps in the COMIT market.
We currently emit order matches in cnd that are followed by sending a swap request to the matching peer. If we both sent and received a matching swap request we start swapping (i.e. the swap becomes available on cnd's /swaps endpoint with Alice having the fund action).

Settling a Limit Order in one swap with matching quantities but different price:
 

Rule (1) - An order matches if both parties get at least the price they asked for.

Example:

Alice publishes a sell limit order:

BtcDaiOrder: {
    position: sell,
    price: 12000,
    quantity: 1
}

She wants to get at least 12000 DAI for her 1 BTC.

Bob publishes a buy limit order:

BtcDaiOrder: {
    position: buy,
    price: 12001,
    quantity: 1
}

He is willing to give 12001 DAI for getting 1 BTC.
The two orders should match!( Keep in mind that there is not only two persons in the market. So, if I really want a trade to happen I offer a better price. That is what Bob is doing.)

When it comes to the domain of swaps we initially found the "settle at a better price than the order" behaviour tricky, because we have to agree on the quantity for the swap.

I think it's easy to have a consensus rule here: the smallest quantity is the one to be used.

I think we can establish rule (1) and settle at the price of the newer order, if the price is favourable for the older order's side.
For the above scenario both should:
1. Have a match
2. Send a Swap with price 12001
3. If either party sends the swap, but never receives a swap from the other party, the reputation should be decreased.

Let's not go so fast regarding reputation. Maybe Alice already executed the swap with someone else! Or she wanted to "withdraw" her order. (ok I see you already mentioned that later)

Settling a Limit Order in multiple swaps (i.e. partial filling):

In addition to rule (1):

Rule (2) - When an order matches on price, but the quantities don't match, the order with smaller amount is settled as swap. The remaining part of the order that was not completely filled stays in the market until a match is found.

          Rule (3) - When cancelling an order, the open part will be cancelled, part of the order in any other state cannot be cancelled. Order.state = 'open' | 'settling' | 'closed' | 'failed' | ' cancelled'. Currently each state is represented as % of the order quantity, rounded to 2 positions after the point.

At the moment it is not possible to cancel an order.

Maybe instead, Ambrosia for the party that only partially had their order fulfilled should send a new order for the same price and remaining quantity.

Settling a Market Order:

When sending a buy Market Order to our cnd:
1. Take all the current sell orders we know, excluding our own.
2. Take the sell order with the lowest sell price.
3. Emit market order match and send swap request.

What defines a "market order" in the DexOB? Cf. the start of my reply. Currently we have "kind of" limit order in the DexOB. I think we can make them proper limit orders and that can be a type of order that works with the DexOB.

I'd expect Ambrosia to generate limit orders that matches existing limit orders to fulfill the market order.

When processing an incoming buy Market Order from another peer:
1. Take all the sell orders, including our own.
2. If the sell order with the highest price is ours: Emit market order match and send swap request.

That's the thing here, so I can put a limit order at $100,000 for 1 BTC so I can sell my BTC at $100,000 when I receive a market order?

It is simply not realistic to broadcast market orders on a DexOB. On a CEX, the exchange does the calculations and order fulfilling so it can actually give you a market order.

On a DexOB, you cannot trust other parties to give you a "market price". Please refer to my proposal earlier on.

For sending/receiving a market sell order the behaviour is flipped accordingly.

Note that in combination with partial filling this can result in settling an order in multiple swaps at multiple prices :)

---

[1] https://www.investopedia.com/ask/answers/04/022704.asp

Cheers,
Daniel

Cheers,

Franck

[Daniel Karzel]

On 8/9/20 11:30 am, Franck Royer wrote:

[snip]

Limit Order and Market Order are general financial terms outside the crypto world.

Forex Order Model Recap: https://3.basecamp.com/4403044/buckets/15109376/messages/2878398232
This model describes a Limit Order.

The Limit Order:

A Limit Order is an order where we specify a price limit.
The order will only be matched once the price reaches the specified limit.
Limit orders are publicly available (i.e. visible) in the market directly after creation.
A limit order does not necessarily settle at exactly the price specified. It settles at at least the specified price (i.e. it can settle at a better price).

So at the moment, we kind of have limit orders but they are more restricted:

- We only match exact price, not exact price or better

- We only match exact quantity. Limit order could be partially settled, matching with several smaller order

This makes me think that we should review and aim to make our order actual limit orders.

Yes!

The Market Order:

The market order (or "best" order, or "best price" order) is an order that does not specify a price.
It only specifies a quantity that we want to buy/sell.
The best market price is selected automatically for you when publishing such an order.

Effectively this means:
When publishing a sell market order the best price is determined as the highest buy price currently on the market.
When publishing a buy market order the best price is determined as lowest sell price currently on the market.

This kind of matches our "best" button order.

In our case, we kind of place a limit order (see above) with the best price. The difference with a proper market order is that if someone else takes the best price before us then

no execution happens. Whereas on a central exchange, it will continue to execute the order (and tell you the price afterwards).

I think this feature is hard to implement on a DexOB. However, being able to place proper limit order at a best price could be a nice replacement in the short/medium term.

If we want to do a proper market order then I would expect the following flow (taking in account our current design).

1. User choose quantity to sell/buy and click "market order". Let's say buy 5BTC

2. Ambrosia looks at current order book,  see a 2 BTC limit order at $10,000 and a 4BTC limit order at $11,000.

3. Ambrosia broadcast a 2BTC limit order at $10,000 and a 3BTC limit order at $11,000

4. The other party sees the 2BTC limit order, it then gets fully executed

5. The other(other) party see the 3BTC limit order, it gets fully executed. The other party's order (4BTC) is only partially executed.

6. Ambrosia report back to the user and says that the market price for those 5BTC where (2 * 10,000  + 3 * 11,000)/5= $10,600.

The best button can substitute for market orders in the beginning. From what you have stated, and what I could refine in my mind, market orders will only make sense if we have significant liquidity in the market. Then a certain "best" price is likely to not fluctuate too much.
This leads me to the conclusion that we should wait with introducing market orders and focus on limit orders.

Note that some market places implement more elaborate orders like stop orders (also called stop-limit orders), that take into account when a limit order becomes publicly visible [1].

Some more thoughts on orders:

As far as my understand goes, market orders are important for bringing trading volume into a market, i.e. how much quantity of a currency is traded during a time interval.

It's more that makers create limit orders and "market orders" are the easiest order to use. You don't try to predict a price, or plan in advance. You just want to sell/buy now at the current price. It's the "simplest" way to trade.

But again, being able to place a proper limit order at the current best rate is a good way to have pseudo-market orders on the DexOB.

If there is only limit orders in a market, and both sides don't move the market is "stale", i.e. no orders get executed.

True, until someone replace a limit order with another one that is executable.

Excursus:

Bid: The current best buy price. I think that eventually we will have to weight this by volume, because the price is bound to a certain quantity at that price.

This is not a feature available on the exchanges I am familiar with. Can you define "current best buy" using trading terms? Are you talking about limit order at best price? If so, then yes of course if the quantity of your order is bigger than

the quantity of the best price limit order on the trading book, then your limit order will not execute completely. That is something that is expected on a CEX so I don't think we should get out our way and make something better.

This goes towards what to display for coming up with the current "market price" and how central exchanges do this at the moment. Poloniex used to display Bid and Ask separately, but recently changed it to a similar view as Kraken.
I also thought quite a bit about, if the volume of the current orders in the market reflects price finding. But these are discussions that lead to far, we can discuss that over concrete UI problems at some point rather than here.

[snip]

When it comes to the domain of swaps we initially found the "settle at a better price than the order" behaviour tricky, because we have to agree on the quantity for the swap.

I think it's easy to have a consensus rule here: the smallest quantity is the one to be used.

I think we can establish rule (1) and settle at the price of the newer order, if the price is favourable for the older order's side.
For the above scenario both should:
1. Have a match
2. Send a Swap with price 12001
3. If either party sends the swap, but never receives a swap from the other party, the reputation should be decreased.

Let's not go so fast regarding reputation. Maybe Alice already executed the swap with someone else! Or she wanted to "withdraw" her order. (ok I see you already mentioned that later)

In a way reputation is something that can be added later. But we should keep it in mind.
I think we should give some reputation a try early, for an isolated use case. Early feedback on the reputation will give us good learnings I think. I think the above example is fairly straight forward. We don't have to immediately decrease the reputation score, but if we don't get a response from the same user X times then we should. To prevent spamming.

Settling a Limit Order in multiple swaps (i.e. partial filling):

In addition to rule (1):

Rule (2) - When an order matches on price, but the quantities don't match, the order with smaller amount is settled as swap. The remaining part of the order that was not completely filled stays in the market until a match is found.

          Rule (3) - When cancelling an order, the open part will be cancelled, part of the order in any other state cannot be cancelled. Order.state = 'open' | 'settling' | 'closed' | 'failed' | ' cancelled'. Currently each state is represented as % of the order quantity, rounded to 2 positions after the point.

At the moment it is not possible to cancel an order.

Maybe instead, Ambrosia for the party that only partially had their order fulfilled should send a new order for the same price and remaining quantity.

It actually is possible! Cancelling the open part of an order is implemented in cnd :)

[snip]

[Franck Royer]

You did not reply to my previous statement: I don't think market order, at a DexOB protocol level makes sense at all. There is no centralised authority that can fairly complete a market order.

I believe the best we can hope for is a UX that looks like a market order but is actually a combination of limit order at protocol/DexOB level

 

[snip]

When it comes to the domain of swaps we initially found the "settle at a better price than the order" behaviour tricky, because we have to agree on the quantity for the swap.

I think it's easy to have a consensus rule here: the smallest quantity is the one to be used.

I think we can establish rule (1) and settle at the price of the newer order, if the price is favourable for the older order's side.
For the above scenario both should:
1. Have a match
2. Send a Swap with price 12001
3. If either party sends the swap, but never receives a swap from the other party, the reputation should be decreased.

Let's not go so fast regarding reputation. Maybe Alice already executed the swap with someone else! Or she wanted to "withdraw" her order. (ok I see you already mentioned that later)

In a way reputation is something that can be added later. But we should keep it in mind.
I think we should give some reputation a try early, for an isolated use case. Early feedback on the reputation will give us good learnings I think. I think the above example is fairly straight forward. We don't have to immediately decrease the reputation score, but if we don't get a response from the same user X times then we should. To prevent spamming.

Settling a Limit Order in multiple swaps (i.e. partial filling):

In addition to rule (1):

Rule (2) - When an order matches on price, but the quantities don't match, the order with smaller amount is settled as swap. The remaining part of the order that was not completely filled stays in the market until a match is found.

          Rule (3) - When cancelling an order, the open part will be cancelled, part of the order in any other state cannot be cancelled. Order.state = 'open' | 'settling' | 'closed' | 'failed' | ' cancelled'. Currently each state is represented as % of the order quantity, rounded to 2 positions after the point.

At the moment it is not possible to cancel an order.

Maybe instead, Ambrosia for the party that only partially had their order fulfilled should send a new order for the same price and remaining quantity.

It actually is possible! Cancelling the open part of an order is implemented in cnd :)

Can someone describe how it works?

[snip]

[Daniel Karzel]

I don't see the need of a central authority for that. Cnd's matching engine can collect all orders and match the what is considered best for you, as described in the original email:

Settling a Market Order:

When sending a buy Market Order to our cnd:
1. Take all the current sell orders we know, excluding our own.
2. Take the sell order with the lowest sell price.
3. Emit market order match and send swap request.

When processing an incoming buy Market Order from another peer:
1. Take all the sell orders, including our own.
2. If the sell order with the highest price is ours: Emit market order match and send swap request.

Settling market orders at a "good" price requires a certain amount of orders in the market (i.e. trading volume).
I don't fully understand you concerns. You state that a DexOB cannot fairly complete a market order. What is "unfair" in your eyes?
I don't have a problem with focussing on Limit orders, but I think Market orders are possible in a DexOB.

 

[snip]

When it comes to the domain of swaps we initially found the "settle at a better price than the order" behaviour tricky, because we have to agree on the quantity for the swap.

I think it's easy to have a consensus rule here: the smallest quantity is the one to be used.

I think we can establish rule (1) and settle at the price of the newer order, if the price is favourable for the older order's side.
For the above scenario both should:
1. Have a match
2. Send a Swap with price 12001
3. If either party sends the swap, but never receives a swap from the other party, the reputation should be decreased.

Let's not go so fast regarding reputation. Maybe Alice already executed the swap with someone else! Or she wanted to "withdraw" her order. (ok I see you already mentioned that later)

In a way reputation is something that can be added later. But we should keep it in mind.
I think we should give some reputation a try early, for an isolated use case. Early feedback on the reputation will give us good learnings I think. I think the above example is fairly straight forward. We don't have to immediately decrease the reputation score, but if we don't get a response from the same user X times then we should. To prevent spamming.

Settling a Limit Order in multiple swaps (i.e. partial filling):

In addition to rule (1):

Rule (2) - When an order matches on price, but the quantities don't match, the order with smaller amount is settled as swap. The remaining part of the order that was not completely filled stays in the market until a match is found.

          Rule (3) - When cancelling an order, the open part will be cancelled, part of the order in any other state cannot be cancelled. Order.state = 'open' | 'settling' | 'closed' | 'failed' | ' cancelled'. Currently each state is represented as % of the order quantity, rounded to 2 positions after the point.

At the moment it is not possible to cancel an order.

Maybe instead, Ambrosia for the party that only partially had their order fulfilled should send a new order for the same price and remaining quantity.

It actually is possible! Cancelling the open part of an order is implemented in cnd :)

Can someone describe how it works?

Orders have a quantity. Orders have five different states, that the quantity can be spread over: open, closed, settling, failed, cancelled.

Assuming that we don't have partial order filling yet:

Initially the complete quantity is in open.
When an order has a matching swap the complete quantity moves from open to settling.
Once the swap is finished it moves from settling to closed.
If the swap fails it moves from settling to failed.
If the user cancels the order it moves to cancelled. At the moment the user can only cancel the complete order, as long as everything is in the open state (i.e. the order has not been matched).

Assuming partial filling (Not implemented yet):

We initially created an order with quantity 1 BTC.
0.1 BTC already got settled and are closed.
0.2 BTC are currently being settled in another swap.
Since we expect the price to change we don't want to wait for the rest to settle, and cancel the rest.

This would result in (simplified in Bitcoin, the amounts are actually in Sats and represented as string):

BtcDaiOrder {
  position: ...,
  price: ...,
  quantity: 1,
  state: {
    open: 0,
    closed: 0.1,
    settling: 0.2,
    failed: 0,
    cancelled: 0.7,
  }
}

Upon cancellation, if the open amount is 0 we additionally remove the order from the orderbook.

Note that previously we used percentage of the quantity to represent the state. This is cumbersome for the UI (and cnd for that matter...).
This is the PR that changes it to quantities: https://github.com/comit-network/comit-rs/pull/3140

[snip]

[Franck Royer]

On Tue, 8 Sep 2020 at 21:32, Daniel Karzel <dan...@coblox.tech> wrote:
[snip]

>
> I don't see the need of a central authority for that. Cnd's matching engine can collect all orders and match the what is considered best for you, as described in the original email:
>
> Settling a Market Order:
>
> When sending a buy Market Order to our cnd:
> 1. Take all the current sell orders we know, excluding our own.
> 2. Take the sell order with the lowest sell price.
> 3. Emit market order match and send swap request.
>

I think this explanation is too abbreviated. What do you mean by "Emit
market order match"? Emit from the orderbook to cnd?
When do you send an order on the network? Is the order you send to
the network the same than the other orders?

>
>
> When processing an incoming buy Market Order from another peer:

What is the difference between a "market order" and a current order in
the orderbook?

>
> 1. Take all the sell orders, including our own.
> 2. If the sell order with the highest price is ours: Emit market order match and send swap request.

So you are saying that a "market order" is priceless. So when you
receive it, you look at your pool of order. If the best order is your
order then you proceed with the match.

I see several issues with the design:
1.It introduces a new type of order in the orderbook, a "market" or
priceless order.
2. The new matching logic as higher false-positive risks.

I don't think that (1) is necessary to brought in a market order
feature. Please refer to my previous email where I explain how we can
reach this feature while using our current "kind of limit" orders.

Let me explain (2) a bit more:

With the current matching logic, for the consensus to be reached and
no false positive to be present, the following needs to happen, in
their respective pools:
- Alice needs to have her order and Bob's order
- Bob needs to have his order and Alice's order

An exact match then ensues, Alice and Bob execute the swap.

A false positive could happen as follow:
- Alice has her order and Carol's order
- Bob has his order and Alice's order
- Carol has her order and Bob's order

Carol then try to execute with Bob
Bob tries to execute with Alice
Alice tries to execute with Carol

This scenario is possible but unlikely, simply because if Alice has
Carol's order then it is very likely that Carol has Alice's order.

Side question: If you have 2 orders in your pool matching one of your
orders, which one do you take?

Now, let's look at the proposed logic, for the consensus to be reached
and no false positive to be present, the following needs to happen, in
their respective pools:
- Alice needs to have her order, Bob's order and Bob's order is the best price
- Bob needs to have Alice's order, his order, and his order is the
best price (for Alice)

A market match then ensues, Alice and Bob execute the swap.

However, because there is a "best price among all order" component to
the logic, it creates a risk of false positive in the case of all
participants of the networks are not aware of all the orders of the
network:
- Alice has her order, Bob's order and Carol's order (which is better
than Bob's)
- Bob has his order, Alice's order, his order is best
- Carol has Alice order's and David's order. David's order is best (for Alice).

Alice tries to execute with Carol
Bob tries to execute with Alice
Carol does not do anything.

This scenario is very plausible, especially if:
- Bob is not connected to Carol
- Alice is not connected to David
- Bob "banned" Carol due to reputation
- etc

In conclusion, the proposed "market order" orderbook logic not only
does not seem necessary to me but would also create consensus
discrepancies that would affect the experience and reputations of the
users.

>
> Settling market orders at a "good" price requires a certain amount of orders in the market (i.e. trading volume).
> I don't fully understand you concerns. You state that a DexOB cannot fairly complete a market order. What is "unfair" in your eyes?

I stand corrected, I did not fully understand the proposed flow until now.

> I don't have a problem with focussing on Limit orders, but I think Market orders are possible in a DexOB.

I think they are possible in cnd/nectar/ambrosia. I don't think we
need market orders in the DexOB to give a market order UX. See my
argumentation above.

[snip]

>> It actually is possible! Cancelling the open part of an order is implemented in cnd :)
>
> Can someone describe how it works?
>
>
> Orders have a quantity. Orders have five different states, that the quantity can be spread over: open, closed, settling, failed, cancelled.
>
> Assuming that we don't have partial order filling yet:
>
> Initially the complete quantity is in open.
> When an order has a matching swap the complete quantity moves from open to settling.

(A)

> Once the swap is finished it moves from settling to closed.

(B)

> If the swap fails it moves from settling to failed.

(C)

> If the user cancels the order it moves to cancelled. At the moment the user can only cancel the complete order, as long as everything is in the open state (i.e. the order has not been matched).

(D)

>
>
> Assuming partial filling (Not implemented yet):
>
> We initially created an order with quantity 1 BTC.
> 0.1 BTC already got settled and are closed.
> 0.2 BTC are currently being settled in another swap.

In (A), (B), (C), (D), Do you mean a new order is broadcast, exactly
the same than before, but with a different status?

> Since we expect the price to change we don't want to wait for the rest to settle, and cancel the rest.

Do you mean a new order is broadcast with a cancel status?

[Daniel Karzel]

On 9/9/20 11:46 am, Franck Royer wrote:

On Tue, 8 Sep 2020 at 21:32, Daniel Karzel <dan...@coblox.tech> wrote:
[snip]

I don't see the need of a central authority for that. Cnd's matching engine can collect all orders and match the what is considered best for you, as described in the original email:

Settling a Market Order:

When sending a buy Market Order to our cnd:
1. Take all the current sell orders we know, excluding our own.
2. Take the sell order with the lowest sell price.
3. Emit market order match and send swap request.

I think this explanation is too abbreviated. What do you mean by "Emit
market order match"? Emit from the orderbook to cnd?
When do you send an order on the  network? Is the order you send to
the network the same than the other orders?

When processing an incoming buy Market Order from another peer:

What is the difference between a "market order" and a current order in
the orderbook?

The current order is a Limit Order. It defines a price. The Market Order would not define a price (as you stated below).

1. Take all the sell orders, including our own.
2. If the sell order with the highest price is ours: Emit market order match and send swap request.

So you are saying that a "market order" is priceless. So when you
receive it, you look at your pool of order. If the best order is your
order then you proceed with the match.

Yes.

I agree with you, it has a higher false positive rate - for it to be a good user experience we largely depend on how well orders are distributed over the network.

The only reason why I brought up the market order in the first place: In the UI we basically have to wait for a match because of the Ledger interaction.
If using the "best" button yields a match fast enough (the user waits) then we potentially NEVER need market orders as described.

We don't have users yet. Only by users trying the UI we can evaluate where we optimize, so Ledger Interaction happens as fast as possible.
I think we had great insight into how Market Orders could work, and what are downsides of them.
I would not invest brainpower in that path any more until after project Ambrosia :) - i.e. no Market Orders in the near future.

Settling market orders at a "good" price requires a certain amount of orders in the market (i.e. trading volume).
I don't fully understand you concerns. You state that a DexOB cannot fairly complete a market order. What is "unfair" in your eyes?

I stand corrected, I did not fully understand the proposed flow until now.

I don't have a problem with focussing on Limit orders, but I think Market orders are possible in a DexOB.

I think they are possible in cnd/nectar/ambrosia. I don't think we
need market orders in the DexOB to give a market order UX. See my
argumentation above.

Agreed, see above.

[snip]

It actually is possible! Cancelling the open part of an order is implemented in cnd :)

Can someone describe how it works?


Orders have a quantity. Orders have five different states, that the quantity can be spread over: open, closed, settling, failed, cancelled.

Assuming that we don't have partial order filling yet:

Initially the complete quantity is in open.
When an order has a matching swap the complete quantity moves from open to settling.

(A)

Once the swap is finished it moves from settling to closed.

(B)

If the swap fails it moves from settling to failed.

(C)

If the user cancels the order it moves to cancelled. At the moment the user can only cancel the complete order, as long as everything is in the open state (i.e. the order has not been matched).

(D)

Assuming partial filling (Not implemented yet):

We initially created an order with quantity 1 BTC.
0.1 BTC already got settled and are closed.
0.2 BTC are currently being settled in another swap.

In (A), (B), (C), (D), Do you mean a new order is broadcast, exactly
the same than before, but with a different status?

Sorry for not being precise enough here, I should have taken a bit more time with the answer.
After checking with Thomas:

First, there is not boadcasting of orders. This was removed shortly before project Tantalus already.
Current model: When a new connection to / from a peer is established cnd automatically, periodically polls that peer for orders.

Second, the state of the order is something internal. From the outside you only see the order with a certain quantity. The state is not visible.
When the open amount of an order changes (i.e. moves from open to settling / cancelled) the order is re-published with an adapted amount. Connected peers will see the amount change upon polling orders.
Once there is no open amount the order is removed, i.e. not publicly available any more.

Since we expect the price to change we don't want to wait for the rest to settle, and cancel the rest.

Do you mean a new order is broadcast with a cancel status?

The state is internal, please refer to the answer above. Additionally: I'd prefer state over status.

This would result in (simplified in Bitcoin, the amounts are actually in Sats and represented as string):

BtcDaiOrder {
  position: ...,
  price: ...,
  quantity: 1,
  state: {
    open: 0,
    closed: 0.1,
    settling: 0.2,
    failed: 0,
    cancelled: 0.7,
  }
}

Upon cancellation, if the open amount is 0 we additionally remove the order from the orderbook.


Note that previously we used percentage of the quantity to represent the state. This is cumbersome for the UI (and cnd for that matter...).
This is the PR that changes it to quantities: https://github.com/comit-network/comit-rs/pull/3140

[snip]

Cheers,
Daniel