Re-thinking limit order trade execution

[VolleyFire]

I’d like to recommend some R&D to be done on re-thinking the trade execution behavior at the smart contract protocol level. This is specifically related to both KeeperDAO’s limit order use case and open orderbook’s limit order use case. It’s possible there are more use cases as well.

Goals:

• Improve gas efficiency.
• During an Arb/MEV extraction transaction, the order can always get filled 100% without any awkward situations/math/unpredictable challenges.
• The 0x user’s order is always the first trade in the MEV extraction which maximizes efficiency
• The above leads to → the order can always get filled 100% without any math complications.
• Keepers & bot traders do not need any tokens to execute this trade, nor do they ever need to flash loan from a liquidity source since the user is the liquidity source. So there’s no capital risk for the bot.

This was inspired by the way CowSwap executes trades.

Comparison of 0x vs CowSwap:

Today, for a bot to aribtrage a 0x limit order and extract MEV for the user, the bot must transact like this. The bot pays Uniswap, then receives a token. The bot takes that token and pays the 0x user and the 0x user pays the bot. It’s critical to nice here that in order for this trade to take place, the bot needed to have 1.77 WETH in order to begin the trade.

Here’s the way CowSwap is transacting for the same type of trade. The user’s makerToken is first given to the bot, think of it as a flash loan. The bot takes that token and pays Sushiswap then receives another token. The bot now has the token that the user wants, so they give that token back to the user and repay the effective loan. Notice that the bot did not need any tokens in order to perform this transaction.

Observations:

• Somehow CowSwap seems more gas efficient than 0x. A more detailed gas usage comparison should be done here. Note: it could be differences in token transfer costs.
• The user’s order is always first in the tx which makes math much simpler for the bot. This easily enables the bot to fill the order to 100% full. If the user’s order was in the middle of the trade, or at the end of the trade, it makes math difficult and risks there being a scenario where the bot has to settle for underfilling the user’s order even if it’s by a super small %. A user would much prefer their order to be filled to 100% as opposed to 99.99%.
• The bot doesn’t need any funds to perform trades and extract MEV.
• If for some reason the bot does not return enough takerTokens to the user based on their order price, the protocol should revert the transaction
• The protocol would essentially be expecting the bot to pass in the 2nd half of the trade as a calldata that gets executed within. I’m worried this would somehow introduce a gas inefficiency due to calls being made back and forth between the trading contract and the bot during the trade execution process. Some research would need done here to optimize that.
• It seems that for CowSwap their logic that’s executing the trade is on the same contract that is being called to trade. AKA the bot’s contract is the same as the protocol’s contract. AKA making internal calls instead of external calls saves on gas. Compared to KeeperDAO today which has to make external calls to 0x’s contracts.

[nikita]

Seems timely and worthwhile. Any thoughts on “who” (person or organization) might be qualified to do the R&D, how long it would take, costs, etc.?

[VolleyFire]

I’d be a great candidate to do it, but I don’t have the bandwidth right now. Anyone who’s developing contracts and has a good understanding of gas optimizations and flash loans. There’s likely a few on the 0x team. Likely others in the community as well.

[VolleyFire]

I started some R&D on this topic. There’s definitely a fair amount of work here, but the initial outlook is all positive and would greatly benefit the user in terms of gas efficiency which directly leads to a better trade price and/or more MEV capture. So one question here is: Is this something we should pursue under the 0x umbrella or is this something that KeeperDAO should spin-off on its own? If it’s under the 0x umbrella then the feature would ultimately live on the 0x protocol and go through 0x auditing procedures. If this is spun off as a KeeperDAO feature then we would take it on our end.

There’s certainly a great deal of benefits for KeeperDAO, and the same benefits apply to 0x open orderbook as well. We could brainstorm on benefits for RFQ (where the user is the taker), but as it stands the benefits are for when the end user is the maker of the order (aka a limit order).

[mintcloud]

Reading this just now @VolleyFire, I’m glad you’ve started researching this field. Let’s chat about this in our next call, ideally we would bring this into the 0x protocol limit order execution (on open orderbook)