Approach for Track 2

This writing proposes an approach for Track2, Execution quality and verifiability across DEX trading platforms. It serves as an early draft providing direction and reference points for future discussions. # Research goals **The primary objectives of this research are to:** 1. Compare the execution quality of various DEX trading platforms, including aggregators (1inch, Paraswap, 0x) and intent protocols (Bebop, 1inch Fusion, CowSwap, UniswapX). 2. Investigate the potential benefits of Coincidence of Wants (CoW) in matching user orders across multiple domains. 3. Examine the potential for improved pricing and liquidity through cross-domain swaps. Answering these questions will provide valuable insights into the current state of DEX trading and help identify areas for future improvement, ultimately benefiting the industry by promoting more efficient and cost-effective trading solutions. # Research topics ## Trading today ### Platform comparison 1. Collect trade request and settlement data for each platform on Ethereum and Arbitrum. 2. Compare the following metrics: - Final price vs. promised price, Binance price, and historical YakSwap quote at the time of request and settlement - Speed - Fail rate - Cost (gas and slippage) ### Solving sustainability 1. Investigate the profitability of intents to solvers without protocol incentives (eg. COW tokens). Namely, determine the minimal profit needed for rational solver to fill the intent. Additionally, attempt to find delta between best price and the filled price. ## Trading tomorrow ### CoW Suppose there was an honest centralised dark pool that would collect user's orders accross multiple domains. Analyze the potential savings for users with CoWs, considering: - User savings for varying waiting times (X seconds) in cross-domain and single-domain scenarios - Volume reduction in markets due to CoW - Liquidity required to facilitate cross-chain matching (expressed as liquidity/volume) ### Cross-domain swaps 1. Investigate potential price improvements for users by tapping into liquidity across different domains. * eg. A solver optimizes a user's swap on Ethereum by sourcing liquidity from Binance and Arbitrum, filling the order on Ethereum while managing risks, and simultaneously capturing orders on Binance and Arbitrum to improve execution price. 2. Estimate the liquidity needed to facilitate cross-domain swaps. # Data Requirements ### Platform comparison * **For every platform** * For trade request (live or close to live) * requestTimestamp * amountIn * amountOutEstimate * assetIn * assetOut * For every settlement * settlementTimestamp * filledAmount * amountOut * gasUsed * gasPrice * transactionIndex * success * Quote API * Random sample of the same request accross different protocols * **Live and deep local Binance order book** * Used to compare quoted prices to Binance * Local Binance order book with variable depth updated using websockets (working POC already implemented on my side) * **YakSwap back in time** [experimental / not recommended] * YakSwap can find the best price accross all supported pools * Cannot do trade splitting and does not support PMM ### Solving sustainability * Trade requests and settlements for every intent protocol (similar to Platform comparison) * Live and deep local Binance order book (similar to Platform comparison) ### CoW * All swaps accross investigated chains * All aggregators; intent platforms and dexes * Properties of each trade: * amountIn * amountOut * tokenFrom * tokenTo * settlementTimestamp * gasCost * chainId ### Cross-domain swaps * Quote API for aggregators and intent provides accross different domains * In house local quoters [not recommeneded] * For optimal amount considerations local searching program would be required * This would be a considerable effort to implement # Deliverables 1. A comprehensive research paper addressing the background and specified questions. 2. An open-source repository containing: - Scripts for fetching trade requests and settlements from different platforms - Comparison and analysis tools - Logging functionality 3. A public dataset containing the collected swap data.