Table of Links Abstract and 1. Introduction Abstract and 1. Introduction Background
Related Work
MEV Discovery
MEV Extraction
Conclusion and References Background Background Related Work Related Work MEV Discovery MEV Discovery MEV Extraction MEV Extraction Conclusion and References Conclusion and References 4 MEV Discovery The initial stage of our methodology involves identifying profitable opportunities on Algorand’s FCFS network. Given the substantial number of arbitrages on Algorand [20], we focus on developing an algorithm to detect these opportunities. Prior research on Ethereum by Zhou et al. [18] demonstrated real-time cyclic arbitrage detection using a greedy method on a small set of assets, with trade input discovery through gradual increments. In this work, we propose a real-time algorithm tailored to Algorand’s specific time constraints, aiming to identify nearly all emerging arbitrage cycles and incorporate a more efficient input optimization technique. To evaluate our algorithm’s efficacy, we collect state data from Algorand and execute the algorithm subsequent to each block’s finality. We present results in both unconstrained and timeconstrained settings, with the latter being more relevant for the competitive dynamics of an FCFS network. This approach allows us to assess the algorithm’s practicality and efficiency in a real-world blockchain environment. 4.1 Cyclic Arbitrage Detection Algorithm The algorithm is confined to operate within a predefined time window τ , which, for FCFS networks, depends on the arrival time of the first transaction, changing a relevant pool’s state. In such networks, the desired position in a block can only be achieved by correctly timing the transaction issuance and propagation to the network. In fee-based blockchains such as Ethereum, min τ is equal to block time (ignoring network propagation latency), as the targeted position can still be obtained by issuing a transaction with sufficient fees at any time before the block is mined. 4.2 Empirical Evaluation Setup To test the performance of our algorithm, we constructed a historical state data collection setup. Leveraging the API capabilities of the Algorand node, we establish a process that continuously listens to our node by invoking the /v2/status/wait-for-block-after/round endpoint[14]. This method sets up an internal wait channel within the node that unblocks upon reaching the desired round, thus notifying us of new blocks. Concurrently, we utilize SDK utilities of various DEXs on the Algorand network to fetch reserve data of pools following the CPMM price invariant. This data, essential for arbitrage discovery, is stored for each round, maintaining a continuous and comprehensive market overview. ALGO token price data for revenue calculation is fetched from [4]. 4.3 Limitations In our methodology, we faced certain constraints that are important to consider. Firstly, there is no known forking tool on Algorand (such as Ganache[15] on Ethereum) which would allow us to construct the blockchain state at a desired block and execute a transaction. Thus, we built our pipeline for constructing historical states. Due to the limitation of this approach, we focused on only a subset of assets, pools, and DEX protocols. For example, we had to exclude the HumbleSwap DEX as it did not provide an SDK with low latency. Hence, the arbitrages we discover on the finalized blocks only represent a lower bound. Additionally, our approach focused on collecting state data on finalized blocks rather than a more comprehensive network-level data collection on the mempool, likely leads to underestimating total arbitrage opportunities. We also simplified our financial modeling, disregarding flash loan fees and assuming the immediate availability of initial assets, which might not reflect real-world trading conditions. 4.4 Results We have tracked 136 assets, exchanged in 255 pools, on three different DEXs (TinymanV1, TinymanV2, Pact), starting from block 32 608 011 (Thu, 05 Oct 2023 00:49:42 GMT) until block 33 039 007 (Sat, 21 Oct 2023 21:05:40 GMT). In these 16 days, 430 996 blocks were built on the Algorand blockchain. In 30 828 (7.1 %) of them, reserves of at least one pool we tracked got updated, and we ran the arbitrage detection algorithm on it. 4.4.1 Unconstrained Arbitrage Discovery 4.4.1 Unconstrained Arbitrage Discovery Before analyzing the time-constrained performance of our algorithm, we let it run unconstrainedly to observe the maximum profitability of block state arbitrages. To benchmark its performance, we also calculate the executed arbitrage profits in the same block range, utilizing the heuristics defined in [20]. Figure 1 displays the revenue plots for arbitrages discovered through our algorithm, which we only ran on finalized block states (blue) versus the arbitrages executed in reality (green). The stark dominance of realized arbitrage revenues showcases that MEV searchers on Algorand promptly exploit arbitrage opportunities inside the block they emerge. Hence, in most cases, price discrepancies do not carry over to the next block. While the maximum realized revenue of an arbitrageur is 167.17 USD, we find, at most, a 32.2 USD opportunity on the block state that is fully closed in the subsequent six blocks. When we manually checked the most profitable ten arbitrages for the window between the position of the opportunity-creating transaction and their respective backruns, we found that the first backrun was always located at the immediate following position. The efficiency of MEV searchers on Algorand in arbitrage execution, in line with the results from [20], showcase that our initial attempt for searching MEV only at the block state level is a naive approach. In future work, we plan to collect transaction data on the mempool directly and execute our algorithm after every trade on a pool relevant to us. This way, we can detect the opportunities when they appear during block construction (not only after the block is finalized) and find their optimal revenue. Currently, we cannot fully assess whether MEV searchers backrunning on the network-level run their strategies with optimized inputs. 4.4.2 Time-Constrained Arbitrage Discovery 4.4.2 Time-Constrained Arbitrage Discovery The success of an arbitrage strategy depends on execution prior to an update in the reserves of the arbitraged pools. We have introduced τ to denote the time window before such an update occurs as part of a competing arbitrageur’s transaction or by an innocent user trade. A competitive arbitrage discovery strategy needs to operate under τ . Hence, in this section, we measure our algorithm’s performance with respect to a spectrum of τ values. Our initial experiments on 430 996 Algorand blocks, in which only 7.1 % of them have an updated pool we track, show that pools relevant for our arbitrage detection algorithm are updated on median every six blocks (25 %: 2.0, 75 %: 17.0); hence τ is close to 19.8 s (block time ≈ 3.3 s). Figure 2 displays the distribution of state update deltas for the examined date range. Interestingly, the max state update delta reaches 294 blocks (∼16 min), although our algorithm does not detect any profitable block state arbitrage in this window. The Value of Time We measure the profitability of our algorithm as a function of τ to observe the impact of the available runtime window on the discovered value. Although we have detected a median state update delta of six blocks (τ = 19.8), due to the competitive nature of intra-block opportunities (see Section 4.4.1), we conduct experiments on a range of τ ∈ [0.2, 19.8]. Additionally, we consider τ = ∞ to encapsulate the maximum profitability in that block. The Value of Time Figure 3 displays the revenue difference percent of τ values to maximum discoverable revenue when τ = ∞, with the mean difference (µ) indicated in the legend of the plot. The results indicate that the discovered arbitrage revenue only significantly degrades when τ is very low (at 0.2 s, 84.39 % less arbitrage revenue is found). On the other hand, almost maximum profitability is reached when τ is close to block time (3.3 s). While the revenue difference we observe depends on the infrastructure we execute the algorithm to measure the runtimes and the size of the pool set we consider, our analysis yields an intuition about the positive influence of available runtime on the discovered value. First-Come-First-Served So far, we have adopted the profit-maximizing, greedy arbitrage selection strategy, as discussed in Section 4.1. However, since we have observed that MEV searchers on Algorand do not leave a significant amount of profits for block state arbitrage, we need to optimize the runtime of our algorithm further to be competitive on the network-level arbitrage. To that extent, we adopt an FCFS strategy for arbitrage selection (as presented in section 4.1), which does not wait to consider all arbitrages available and select the most profitable ones but issues them as soon as their optimal input is calculated. While this strategy can yield less optimal revenue, it potentially saves valuable time. First-Come-First-Served Figure 4 displays the revenue difference between FCFS and profit maximizing strategies, for different τ values. While the disparity is only 5.36 % when the algorithms are run for 0.2 s, the difference between the two strategies becomes more significant with increasing τ values. This is because, with more time, the profit-maximizing strategy discovers a wider set of opportunities and considers all of them when choosing the most profitable arbitrages to be issued. FCFS strategy, on the other hand, will always execute the first arbitrage it finds; hence, with increased time, the probability of finding an arbitrage that overlaps with an already taken one also increases. To minimize the revenue difference between the two approaches, the FCFS strategy requires applying a prioritization rule on the candidate arbitrage cycles before processing them. In our experiments, we sorted candidate cycles based on existing liquidity in involved pools, although more sophisticated rules can be developed by modeling the problem in a machine-learning domain. Authors:
(1) Burak Oz, Technical University of Munich;
(2) Jonas Gebele, Technical University of Munich;
(3) Parshant Singh, Technical University of Munich;
(4) Filip Rezabek, Technical University of Munich;
(5) Florian Matthes, Technical University of Munich. Authors: Authors: (1) Burak Oz, Technical University of Munich; (2) Jonas Gebele, Technical University of Munich; (3) Parshant Singh, Technical University of Munich; (4) Filip Rezabek, Technical University of Munich; (5) Florian Matthes, Technical University of Munich. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv [13] https://scipy.org/ [14] https://github.com/algorand/go-algorand/algod/api/server/v2/ [15] https://github.com/trufflesuite/ganache

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Algorand

Ethereum

We Built a Private Algorand Network to Crack the Code of Transaction Ordering

It’s Not What You Pay, It’s How Fast You Play: A History of MEV

EScholar Technologies

Too Long; Didn't Read

Get Free Unlimited IP Geo Data With IPinfo Lite

Is There Any MEV Left on Algorand? An Empirical Study on Time-Constrained Arbitrage

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Ways to Measure Privacy Risks in Text Data

6 most Eco-friendly Cryptocurrencies in 2021

A Technical Q&A on Network Partition Attacks

AlgoNaut - an Algorand wallet with Tatum

Algorand $ALGO Wiki: Coin History, Techstack, and Crypto News

5 Ways to Measure Privacy Risks in Text Data

6 most Eco-friendly Cryptocurrencies in 2021

A Technical Q&A on Network Partition Attacks

AlgoNaut - an Algorand wallet with Tatum

Algorand $ALGO Wiki: Coin History, Techstack, and Crypto News

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps