 |
June 21, 2012, 02:27:43 PM |
|
This article will be a bit longer a might be difficult to understand (probably cause me explaining it isn't that straight forward) but this question is important to us to and we hope to get your feedback on what you think would be the right logic. Here is a scenario that has been bothering as since a while for which we have multiple solutions.
If you look at the Vircurex's orderbook you will at times find two entries with the same unit price. Impossible you would say, how can that be, when looking at the orderbook you would expect to see the total number of orders for a specific unitprice to be accumulated, e.g.:
You will see as of today:
Buy Orders:
Qty Unitprice
10 0.00029017 BTC/IXC
20 0.00029017 BTC/IXC
5 0.00029100 BTC/IXC
But you were expecting:
30 0.00029017 BTC/IXC
5 0.00029100 BTC/IXC
Right? Obviously there is a logical explanation. Here is where the things get tricky. This seems to be a unique scenario to Vircurex because we allow traders to enter their orders in any currency combination, hence you can enter either
SELL BTC, BUY IXC
or
BUY IXC, SELL BTC
Lets make this clearer on a concrete example:
User 1 places an order: Buy 1 BTC at 0.00029017 BTC/IXC
User 2 places an order: Sell 1 IXC at 3446.25564322 IXC/BTC
When showing the order book for the currency pair BTC/IXC we will need to convert User 2s order into BTC/IXC, so his order will look:
User2: Buy .. BTC at 0.000290170000002
As we only display 8 digits, the two orders both look alike to have 0.00029017 BTC/IXC but they are not exactly the same hence you see two entries.
Your first argument would naturally be: but BTC only has 8 digits after the decimal point. Right, but the counter argument would be: 0.00029017 is smaller than 1/3446.25564322.
We could infact argue the other way round, we convert the BTC/IXC into IXC/BTC, then we would have
User1: SELL … IXC at 3446.25564324 IXC/BTC
User2: SELL … IXC at 3446.25564322 IXC/BTC
As they are both SELL orders, the lower sell order comes first.
Ofcourse we could solve the optical problem by combining the orderbook in such a way that the two entries show summarized. But that does not solve the order matching principle when orders get executed. Then User2's order will still take precedence.
What is the solution:
1. Leave as is because mathematically it is the correct thing to do and leave the orderbook to show the two entries as above
2. Like 1. but combine the two orderbook items to show the sum only. The order trading engine will still match User 2s order first.
3. Always convert orders into one specific direction only. E.g. all BTC/IXC will always be converted to IXC/BTC or visa versa and then after the conversion we perform the rounding to 8 digits. That will make the orders of user 1 and 2 the same. The difficulty here is, in which direction do we convert, especially considering that we have many Alt-chain combinations. We could always convert to .../BTC. But what to do if we have DVC/IOC trades?
4. If we have two such competing orders, then use logic of option 3 in a way, that all orders get convert in the orders format that was placed first, in the above example user 1 placed first therefore user2's order needs to be converted to the currency pair of user 1 and rounded to 8 digits.
So here is the question, which of the options are in fact the result that you would be expecting, or do you have a possible other option?
|
