Closed Henry-E closed 2 years ago
The idea is that a lightweight cancel_order
enables users to fit more into one transaction, which is especially useful for MMs. Users can then add a single settlement instruction for those instructions.
cancel_order
is often a time-critical instruction, so fitting as many as possible into one transaction makes sense. Settlement is often less time-critical.
Cool, makes sense. Thanks!
If the goal is to optimize the number of cancels that can be done in a single transaction, why not have the function take an array of order IDs instead of making the user break the cancel orders into individual instructions? Then the function could just loop over the IDs and cancel the orders.
It might need some testing though to see what the maximum number of orders can be cancelled in a single transaction worth of compute is. Presumably a fully filled orderbook will make it slower to cancel.
This is more of a general design question. What's the logic / reasoning for not autosettling the proceeds of cancelled orders? I.e. why not just send the SPL tokens from the cancelled order straight back to the users wallet from the vault. Why require an extra settling step / instruction?