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.
- 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.
- 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.