Limit Orders - Githubissues

Description CowSwap is great swap interface, it protect us from MEV and allow us to exchange ERC20 at best available prices.

But, what if we don't like the available prices? what if we want to trade at better ones. Sure we don't want to be checking every few hours if the market price is now right for us, specially because this can happen at inconvenient times such as while we sleep.

Limit orders is a feature that makes a lot of sense for CowSwap / Gnosis Protocol, and one that has been asked many times in Twitter, Discord, Feedback form, and testing sessions.

One interesting fact is, technically all orders are limit orders at protocol level. This is, right now, when you sign an order you reveal the maximum price you are willing to pay for the asset you are buying.

So, if all orders are already limit orders, why CowSwap doesn't allow limit orders yet?

First reason is because, market orders UX is simpler. You trade at current market prices. Just exchange this token for this other token. Basically, the main Uniswap UX.

Limit orders, in the other hand, are for slightly more advanced users and would probably need to introduce more elements, like historic prices, volumes, some sense of the current order book, and last executed trades. So it felt not a natural first step in the proof of concept of this Coincidence Of Wants protocol (GPv2).

Another reason is that, limit orders might have additional complexities for the solvers (bigger number of open trades), but also there's another challenge to solve, the economical incentive of the execution of the order.

I don't want to extend too much in this forum about this economical incentive, because https://forum.gnosis.io or Discord would be more suitable, but I want just to mention what is this problem about:

Currently, to send a market order you need to include a fee in your order. This is required to tip the solvers to execute it
This fee cover their service of finding solutions, but also allow them to pay the gas costs of settling the trades on-chain
The fee therefore is a fluctuating value, that depends on several things, two of them being the gas prices and selling token price (you pay the fee in sell token)
Market orders are executed in a few seconds/minutes, so solvers don't expect big price fluctuations in gas/token
Limit orders however can remain in the book for weeks before they are executed, therefore these prices are unknown
Since solvers don't know this price, they can only estimate. At the end, by the time this trade is executed to outcomes can occur: they overpay, or the user overpays. No-one wants any of these outcomes!

One possible solution would be, to let the solvers execute the orders only when price drops enough so they can pay the fee with the generated surplus. This solves the problem! Although, this also mean that the orders won't execute at exactly the price in your limit, but would wait until the price is even better (note this could become a UX problem if we don't manage expectations).

There could be other more advanced solutions, each with their pros/cons, for example implementing some fair system to get the current fee that could be enforced by a contract, so no-one overpays. These family of solutions, would be very interesting, but also more complex in the protocol and UX. It would allow for example, to set some WETH10 or other permitable tokens aside to pay fees.

It looks then, the solution of paying the fee using the surplus would be a good solution as a first step for adding limit orders. To implement this, it would be interesting to research about it's UX and any restrictions, for example:

What happens with very small trades? These will need to generate too much surplus in order to execute, so they will let the price to drop further than bigger ones.
How would this UX would look like. Is allowing to set a price enough? would we also show the current price, and some nice chart? should we implement this together with a classical trading UI or should we just do a PoC first with the bare minimum.
Is there anything we can do to make the user aware that trades don't execute at their limit price, but one slightly lower. This can make people upset if the price only touches their limit price but not continues to raise/fall from there.
Do we have an issue with soft cancelation of orders? For limit orders without deadlines, their signature remains valid even after the soft cancelation. It would require the user to pay to enforce this cancelation. Would we then disallow very long term limit orders?

Proposal This Issue would be to explore further the topics explain above, maybe to define a minimal PoC or define what would an ideal limit order UI would contain.

This issue is also open for comments from anyone, so please let us know your thoughts!

gnosis / cowswap

Limit Orders #1297