Keep in mind that even if the 590 spike was a real trade, it doesn't necessarily mean that you were improperly skipped over with a sell at 545.
A spike from 530 to 590 with a real trade at 590? And skipping over a sell at 545 is okay? Is that some kind of a sick joke?
You have to read the discussion I linked to in order to understand. The point is that it's possible to have a bug where in a bid > ask condition a trade happens @590 even though someone with an ask @545 didn't get skipped over. I'm not saying this is the type of bug we're seeing, but it could be - we haven't isolated the problem yet because it's hard to reproduce and we are staying open about what it could be.
To give a simpler example than I linked to, suppose the order book is in the following bid > ask state:
sell 1 BTC @531
sell 1 BTC @530
buy 1 BTC @590
buy 1 BTC @529
If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590. Does this mean that the ask @531 was skipped over? No, because the ask @530 with its better offer has priority over the ask @531.
This is definitely a bug and should not happen. But the problem that makes it a bug is not that someone got skipped. So, again, my only point that it's possible to have a bug where a trade happens @590 even though someone with a sell @545 didn't get skipped. This is a bug we've seen before and addressed but we may not have fixed all cases of it yet.
I've read and read and read this bold text at least a dozen of times and I can't understand what you say! Who initiates the trade, the sell side with market order or the ask @530 with limit order? Which one of those is matched against the bid at @590?
In the example there are no market orders on the book. Sell side initiates, meaning that it's the ask @530 that initiates the trade and is matched @590 because that's the best buy offer on the book. Of course, what should happen is that the trade should execute @530 and not @590 -
my only point is that if there is a bug and the ask @530 initiates and gets the best bid on the book @590, it doesn't mean that an ask @545 has been skipped. We had this type of bug come up before and people were complaining then too about being skipped, but that wasn't the nature of the problem. Here I'm saying that a similar thing could be happening, so it's not entirely clear that anyone got skipped. Until we figure out how to reproduce the bug and have it fully diagnosed we don't know what exactly the explanation is.
On the contrary, it does mean ask @545 is skipped.
The ask @545 is skipped because it is already on the order book before ask @530 is initiated! Why ask @545 is not matched against the best bid on the book @590 instead matching engine waits for ask @530 to be initiated?
Because a lower sell offer will always take priority over a higher sell offer and get matched first, even if the higher sell offer is placed on the book first. If that wasn't true then there would be no basis at all for thinking the ask @545 was skipped because there might have been an order above it @570 or whatever that was placed first and got matched @590 because it was prior in time. In determining priority of orders it goes first in order of price then by time in the case of orders that are at the same price.
So, what you actually explain now is different. Both ask @530 and ask @545 are already on the order book before bid @590 is initiated, right?
I haven't changed anything but have assumed from the start that the bid @590 is put on the book after the other orders (should have made that clear).
Didn't you say the following:
If the sell side initiates the trade, then the ask @530 should fill at the best price available on the book, which is the bid @590. So the trade executes @590.
There is a very simple solution to this 'bug'.
Out-of-the-market limit orders:
- ask initiated below highest bid
- bid initiated above lowest ask
Every out-of-the-market limit order should be transformed into market order as soon as it is initiated! This is also safety measure against so called 'fat finger' mistakes.