I think metamask could add alot of value to their product if they were to offer in-wallet limit orders to their users specifically through an integration with the KeeperDAO hiding game. The metamask in-wallet swaps currently offer a very convenient way for users to perform token swaps, but I believe the user experience could be significantly enhanced with the introduction of limit orders. If a user wants to execute a swap at a rate that does not equal the current market rate and they believe this opportunity will present itself, they have to be attentive to market movements to time this purchase correctly. Limit orders automate the process for the user and on top of that are also gasless. This is a clear win for the user and also a win for metamask as this allows the capture of transaction flow that might otherwise have been missed either from users’ missed timing or from users being priced out by gas costs.
Rather than building out limit order functionality from scratch, this feature can be introduced through an integration with KeeperDAO. KeeperDAO currently offers the best limit order experience. It is production ready, battle-tested with millions in tx volume per day, and draws on liquidity from all the major dexes and aggregators. Bancor and Metric Exchange have already integrated and offer KeeperDAO limit orders to their users. Below is Bancor’s KeeperDAO limit order integration.
What sets apart KeeperDAO limit orders from other limit order implementations is that they enable users to share in the profit created by their limit orders. In general, the implementation of on-chain limit orders is such that a keeper will fill the limit order when an arbitrage opportunity between the market rate and the limit order rate presents itself. The keeper fills the user’s order at a cheaper rate than the limit order rate and pockets the difference. What KeeperDAO does is they reward users with Rook based on the profit made from their limit order. A certain amount of rook is allotted each day for these rewards and a limit order user’s proportion of those rewards is the proportion of profits from their limit orders with respect to the total profits from limit orders across all users in the day prior to the rewards event. This is described in more detail here Let the games begin. These developments go live 24 hours… | by KeeperDAO | KeeperDAO | Medium . So the amount rewarded will vary based on market conditions, but I’ve personally placed limit orders where the total value in rook rewards I received were greater than the profit captured by the keeper.
There are other compelling reasons to adopt KeeperDAO limit orders that are tangential to giving the best limit order experience to users and that pertain more to the overall health of the ethereum network and fair distribution of protocol+user created value. Limit orders present profit opportunities to the keepers who fill them. In practice, this results in a free for all between keepers who enter gas bidding wars with each other as they try to capture the arbitrage created by limit orders. This affects both keepers and users negatively, as the gas wars eat into the keepers’ limit order profits, and network congestion created by these bidding wars drive gas prices up for everyone. The only people who truly benefit from this are miners who profit massively from these gas wars and in fact could monopolize on these arbitrage opportunities if they wanted by inserting their own transactions into their mined blocks. KeeperDAO only allows whitelisted keepers to fill their limit orders and seeks to coordinate keeper execution of limit orders to eliminate network congesting gas wars between them that by proxy leak profits to miners who arguably deserve none. In doing so they maximize profits captured from these limit orders, putting KeeperDAO in the best position to accomplish one of their main goals which is to redistribute this value to the people who create it, which include limit order users and also, as hinted in the above article, integration partners (e.g. Bancor, Matcha Exchange, Metamask).
