Preserve queue priority on size reductions, but not increases
bogberry opened this issue · comments
Description
The current Econia orderbook implementation uses price-time priority for deciding which orders are filled first: when a price level has multiple orders, orders that were submitted earlier are filled first.
When a user modifies the size of the order, the current smart contract allows a user to retain their place in the priority queue, even if they increased the size of the order. This is problematic because this would allow a trader to
- place trades at the minimum allowed size at every single price level in the orderbook, taking the first position (or at least an early position) in the priority queue at minimal cost, then
- increasing the size of the orders for the price levels they would actually like to have filled, enabling them to place orders while always taking the first spot in the priority queue and giving them an unfair advantage.
Therefore, we should only allow orders to retain queue priority when they are modified so that the size is reduced, not when the size is increased. Queue priority preservation when the size of the order is reduced should be kept in, since allowing this does not allow for similar malicious behavior, and is used by many legitimate trading strategies.
Possible fixes
As for what to do when a user tries to modify an order by increasing its size, we have two main options.
(a) Cancel the existing order and place a new order, which goes to the back of the priority queue
Pros:
- This is the behavior that most users would expect when they increase the size of an order
- Would be consistent with most major exchanges, and would make integration with Econia easier for traders running systems across multiple exchanges
Cons:
- May result in unexpected events being fired
- Refactoring the event emit logic to not fire a cancel / place order event when a modification has been made may be a lot of work
(b) Abort when a user sends in a modification request with a size greater than the current size
Pros:
- Simple to implement
Cons:
- Would be unexpected behavior for most users—even if we clearly document this, most users will expect Econia to behave in a similar manner to how other major exchanges do
- May create friction for trading firms looking to integrate with Econia, as they may have built their systems with the expectation that it is possible to increase an orders' size through a modification
Additional notes
I would highly recommend this be fixed in v4, even if it means additional audits, as it would be a major issue if the orderbooks are manipulated in the manner described above.
Refactoring the event emit logic to not fire a cancel / place order event when a modification has been made may be a lot of work
Agreed that event refactoring for a size increase per proposal (a) may prove burdensome. I judge that this is outweighed by the cons of (b), however, and as a first pass we should plan to implement (a).
Okay, that sounds fine to me. In that case we can have (a) as a potential enhancement to implement down the line.