Modifying the order price should run the matching process about nodejs-order-book

[fasenderos]

@afshinkoohsari I have opened a PR (#341) that addresses the issue, can you double check for me?

[afshinkoohsari]

I truly appreciate your efforts. Thank you.

[fasenderos]

Thanks for reporting. Instead of matching against other orders in the book, we have to raise an error. Because essentially, you are placing a limit buy ABOVE the current market price. LIMIT orders must be rejected if they would immediately match and trade as a taker.

[fasenderos]

Thanks for reporting. Instead of matching against other orders in the book, we have to raise an error. Because essentially, you are placing a limit buy ABOVE the current market price. LIMIT orders must be rejected if they would immediately match and trade as a taker.

I am convinced that the correct approach is to trigger an error. But I have realized that I should modify the entire logic of the limit order. Essentially, a limit order should be accepted and placed in the order book only if it is not executed immediately.

[afshinkoohsari]

I'm not entirely sure, but I believe the distinction should only be in the 'isMaker' flag. If a limit order is executed immediately, it is treated as a taker, whereas if it enters the order book, it should be considered a maker. Additionally, for partial orders, the remaining portion is considered the maker.

Binance explanation

[fasenderos]

You are right. I'll take a closer look

[afshinkoohsari]

Of course.
Another point I found in the Binance documentation is how they treat any update as a new order with a new ID, and the updated order will be appended at the end of the queue, regardless of changes in price or size. I'm not aware if there's a standard method for implementing FIFO matching engines. However, adopting this approach would simplify the implementation, as each update call would create a new order with an IProcessOrder return type.

From Binance:

You can edit an open order’s price and amount if the order hasn’t been fulfilled or is partially filled. Once you edit an order, the previous Order ID will be canceled and a new Order ID will be created.

From another page:

When an order is modified by price or quantity, it will be deemed as a new entry. Under the FIFO algorithm, or price-time-priority algorithm, orders are prioritized according to their order price and order time. Hence, the latest orders will be placed at the back of the matching order queue.

[fasenderos]

Currently, the behavior is more or less like this. The old order is deleted, and a new one is created, but with the same ID
https://github.com/fasenderos/hft-limit-order-book/blob/883c13be0fccc8f457bf99ad5bf2c18430e7f9b7/src/orderside.ts#L91-L101

[fasenderos]

Of course. Another point I found in the Binance documentation is how they treat any update as a new order with a new ID, and the updated order will be appended at the end of the queue, regardless of changes in price or size. I'm not aware if there's a standard method for implementing FIFO matching engines. However, adopting this approach would simplify the implementation, as each update call would create a new order with an IProcessOrder return type.

From Binance:

You can edit an open order’s price and amount if the order hasn’t been fulfilled or is partially filled. Once you edit an order, the previous Order ID will be canceled and a new Order ID will be created.

From another page:

When an order is modified by price or quantity, it will be deemed as a new entry. Under the FIFO algorithm, or price-time-priority algorithm, orders are prioritized according to their order price and order time. Hence, the latest orders will be placed at the back of the matching order queue.

Before v4.0.0, only when the price of an order was changed, the order was deleted from the orderbook and recreated. From v4.0.0 the same behaviour occurs when the size is changed. Moreover the modify function now return IProcessOrder.

Compared to the Binance's behavior, the only difference is that the modified order keeps the same ID. But this can be easily changed if it turns out to be a problem.

This issue can be closed now?