[Protocol3] Cancel all orders new feature

[letsgoustc]

Our current design needs to pay fee for cancel an order, so to save user money, we may need to provide cancel all orders feature. And almost all CEXes support such feature.

We can allow user to cancel all orders related one trading pair or event cancel all pending orders for all trading pair.

[dong77]

This is already possible by submitting an onchain request to change the EDDSA keypair.

[dong77]

The exchange can of course simply delete all use orders or their signatures. This requests user trust of course.

[dong77]

This might be a duplicate of #119

[Brechtpd]

There is a way we could do freely do multiple cancels cheaply in a single operation by updating the trading history root for a tokenS instead of a single leaf, but I didn't do this because:

• This is a bit dangerous because orders that were cancelled can become un-cancelled again because the user has complete freedom to update the leaf values as he wants.
• Nobody but the operator/user know the leaf values of the trading history tree after the update (only the trading history root would be put on-chain with DA). This is still safe for users (balances can be withdrawn in withdrawal mode), but generally limits the exchange to a single operator because that leaf data is not guaranteed to be available.

But there are other ways to achieve this as well (e.g. add a cutoff orderID in the balance leaf, all orders need order.orderID > cutoff orderID or they are cancelled, but this needs some additional logic). But I think actually cancelling like this will not be used a lot because it costs money (so probably only for big orders), people will trust the DEX or they can use other ways to soft cancel orders.

[letsgoustc]

This is already possible by submitting an onchain request to change the EDDSA keypair.

Yes. It works due to our current implementation make sure all the previous orders will be cancelled.

[letsgoustc]

There is a way to freely do multiple cancels cheaply in a single operation by updating the trading history root for a tokenS instead of a single leaf, but:

• This is a bit dangerous because orders that were cancelled can become un-cancelled again because the user has complete freedom to update the leaf values as he wants.
• Nobody but the operator/user know the leaf values of the trading history tree after the update (only the trading history root would be put on-chain with DA). This is still safe for users (balances can be withdrawn in withdrawal mode), but generally limits the exchange to a single operator because that leaf data is not guaranteed to be available.

But there are other ways to achieve this as well (e.g. add a cutoff orderID in the balance leaf, all orders need order.orderID > cutoff orderID or they are cancelled, but this needs some additional logic). But I think actually cancelling like this will not be used a lot because it costs money (so probably only for big orders), people will trust the DEX or they can use other ways to soft cancel orders.

Just like the behavior for updating public key pair. In relay engine we will cancel all active orders but without any verification in circuit. I think it's acceptable because such API's calling frequency will be low and most of them will be called by quantitative traders.

[dong77]

Another factor to consider: order supports a TTL (time to live) therefore DEX frontend can enforce a max TTL for all orders.

[dong77]

I'm closing this issue, feel free to reopen if you feel we need to discuss further. @letsgoustc