Orderbookv1.1

[txhsl]

Problem

Inherit #25. In the past order book and aggregator, we got several problems with the gas fee and stuck orders. Unpredictable aggregation and the high gas fee of FLUND invocation made it expensive to trade with the first order in book, though cheaper to trade with the following because the fundfee is summarized. The result is, we have to pay a high extra sysfee for transactions so that we can deal with a lonely stuck order at the first of the price queue, and it is costive to avoid it in automatic aggregation.

What's Done

• Remove the Aggregator contract, let the user decide whether to deal and how much to deal with existing limit orders. Order book only ensures that users add, deal orders and swap the AMM within the price limit, but no longer provides a trading strategy. (Existing orders will be first fulfilled, and the left goes AMM)
• Remove the buy order price >= sell order price limit of the order queue, so users will not be forced to trigger any orders before adding a new one in some cases.
• Provide some flexible getter methods like GetFirstNOrders(UInt160 tokenA, UInt160 tokenB, bool isBuy, uint pos, uint n), so that the frontend can query anywhere of the order lists and receipt lists.

The total gas cost of limit deal is reduced from 0.4 GAS by 0.2 GAS by removing the automatic aggregation in contract, and the extra sysfee can be reduced from 0.3 GAS to 0.07-0.15 GAS or even 0 if we can predict the payment of FLUND and decide whether to trade with the book.

To Do

The gas payment for clean a stuck order alone are still expensive, they will still get stuck until the next order reach the AMM price. We are considering adding a new endpoint to settle the fundfee instead of doing it in every transaction.

• Record the FLUND payments of every transaction in contract storage instead of paying them immediately. And add a claim method for settlement that allows anyone to transfer the summarized payment to fundAddress. That will reduce two 0.03? GAS transfers in every transaction.
• Add more similar order getter methods like GetFirstNOrders that takes orderID as a parameter instead of the pos.

(Evaluating...)