SoK: Mitigation of Front-Running in Decentralized Finance

Abstract

Front-running is the malicious, and often illegal, act of both manipulating the order of pending trades and injecting additional trades to make a profit at the cost of other users. In decentralized finance (DeFi), front-running strategies exploit both public knowledge of user trades from transactions pending on the network and the miner’s ability to determine the final transaction order. Given the financial loss and increased transaction load resulting from adversarial front-running in decentralized finance, novel cryptographic protocols have been proposed to mitigate such attacks in the permission-less blockchain setting. We systematize and discuss the state-of-the-art of front-running mitigation in decentralized finance, and illustrate remaining attacks and open challenges.

J. Hsin-yu Chiang—This work was supported by the PhD School of DTU Compute.

B. David—This work was supported by the Concordium Foundation and by the Independent Research Fund Denmark (IRFD) grants number 9040-00399B (TrA²C), 9131-00075B (PUMA) and 0165-00079B.

T. K. Frederiksen—This work was supported by “Sikker brug af følsomme data”, Performance Contract 2020 and “Digital sikkerhed, tillid og dataetik”, Performance Contract 2021–2024, Ministry of Higher Education and Science, Denmark”.

L. Gentile—This work was supported by the Concordium Foundation.

Appendices

A Example: AMM Sandwich

We illustrate a step-wise execution of a sandwich in Fig. 5 and introduce notation for user and AMM state proposed in [4] for this purpose. The wallet of is modelled as the term , where $v_0,..., v_n$ are the respective balances of token types . The state of an AMM holding token types and is given by its reserve balances . Thus, we express the system state as a composition of wallets and reserve balances.

Let the initial AMM balance be . User wishes to perform the swap . For simplicity, we assume unit values of and to be equal: given the ratio of AMM reserves is 1, there is no arbitrage opportunity to be exploited [4]. If ’s order is executed immediately, receives for the it sends to the AMM. Instead, however, if the user swap is sandwiched by attacker (Fig. 5), only obtains the minimum amount , implying a reduction of . Note that the reserve product is maintained at each execution step and that the sandwich execution preserves the initial reserve ratio: the attack leaves no arbitrage opportunity unexploited. The attacker ’s profit of 5 units of (or ) is optimal [5]: receives the minimum amount possible, namely its swap limit.

Fig. 5.

Sandwich attack

B Example: Speculative Sandwich

An execution of a speculative sandwich is shown in Figs. 6 and 7: here, adversary observes victim ’s interaction with an AMM which batches blinded inputs. has a public balance of only, allowing to infer that can only perform a left swap from to with an input amount of at most . The attack strategy is executed over two subsequent rounds beginning in the initial state shown in Fig. 6, where we assume unit values of and are equal.

Fig. 6.

Successful speculative sandwich

In the first round $\textsf{r}$, submits the front-run swap in the same direction as the victim’s, with arbitrarily chosen input amount . The minimum output amount or swap limit of the front-run is then is chosen to be such that $(100+7) \cdot (100-6.5) = 100^2$ holds: thus, if the front-run were executed in the initial state, would receive exactly its swap limit. Since all other user orders (other than the victim swap of ) are suppressed, there is a probability of 0.5 that the front-run is randomly evaluated before the victim’s swap, as shown in Fig. 6. The back-run swap of in the opposing direction then follows in the subsequent round with probability 1, since suppresses all user actions other than its own back-run. Assuming equal unit value of both token types, the attack profit for is 3.5.

Should the front-run ordering fail (Fig. 7), then ’s front-run parameters are chosen such that the front-run swap will not execute, resulting in an abort of the speculative sandwich attack. This is due to the chosen front-run parameters: following the execution step of ’s swap in Fig. 7, the constant product invariant can only hold if receives for the it sends: . However, this contradicts swap limit of , such that the front-run cannot execute in the state following ’s swap. can still perform a back-run in round $\mathsf r+1$, thereby restoring the initial reserve ratio and extracting an arbitrage profit of 2, which is less than in the successful speculative sandwich execution in Fig. 6. Still, the speculative sandwich attack is always profitable, as shown in Appendix C.

Fig. 7.

Aborted speculative sandwich

C Formalization: Speculative Sandwich

We formalize the example attack trace introduced in Fig. 4 and prove that the attack strategy is either profitable or cost-neutral for the attacker. Again, we assume unit value of to be equal, and the initial AMM reserve state to be : in this state, there is no arbitrage opportunity to be exploited, simplifying our analysis. We omit both AMM and transaction fees.

The victim swap direction is left, inferred by from ’s public balance of ( holds no units of ). The attack strategy is as follows:

• 1. Round $\textbf{r}$: Front-run victim with such that

  

  (1)

• 2. Round $\textbf{r}+1$: Back-run victim in opposing direction to reestablish initial AMM reserve ratio, or if attacker balance is insufficient, back-run with largest amount available to attacker .

We must show that this strategy is always profitable (when the victim swap direction can be inferred by the attacker). We note that there are several variables beyond the attackers control. The ordering of both front-run and victim swap in round r is random. Thus the desired “front-run” ordering of the victim swap in round r may not succeed (the sandwich is unsuccessful if the victim swap precedes attacker front-run swap). Furthermore, the victim swap parameters can be arbitrarily chosen, so that the victim swap may not be enabled or execute in a given sequence. Thus, we must exhaustively demonstrate the profitability of the attacker strategy for all possible cases:

• 1) Successful sandwich & enabled victim swap

• 2) Successful sandwich & disabled victim swap

• 3) Unsuccessful sandwich & enabled victim swap

• 4) Unsuccessful sandwich & disabled victim swap

Case 1: (successful sandwich & enabled victim swap): We illustrate the symbolic execution of the attack trace below in terms of initial balances, chosen swap parameters and exchanged amounts.

We show that the attack is profitable. For and of equal unit value, the net change in value exchanged by must be positive. Thus, we must prove

(2)

Note that the amounts exchanged in the front-run are equal to the front-run parameters (), as they are chosen such that (1) holds. We consider the sub-case (a) in which the attacker has sufficient balance to perform the back-run swap such that the AMM reserves are restored to the original state and the sub-case (b) in which the attacker initially has no balance of to perform the back-run: . Here, the funds of required to execute the back-run are received entirely in the front-run execution.

For sub-case (a), we rewrite (2) in terms of independently chosen parameters , (the attacker only knows the victim swap direction) and initial reserve amounts ${\textsf{r}_{}}$. The reserves of the AMM are restored to the initial state in final state : summing all step changes to the reserves across the sandwich execution yields

or

Inserting RHS of equations above into our proof obligation (2) yields

(3)

To evaluate whether this inequality holds, we must solve for in terms of and chosen independently by the victim and adversary respectively. We exploit the constant reserve product invariant which holds for across the entire execution.

We can derive from the first equation, and substitute the RHS for in the second equation to obtain

Solving for ...

and substituting the RHS for in the proof obligation in (3) finally yields

(4)

The fraction expression above is less than 1 for any choice of positive and as the numerator is smaller than the denominator. The attacker profit is thus positive and increases with , justifying the front-run swap by .

Next, we consider the sub-case (b), where the attacker initially has no balance of , and restate the profit of attacker for the reader’s convenience.

We assume initial attacker balance in to be , so that all the amount of available for the back-run in state is received in the front-run: thus, substituting into the equation above yields

(5)

To prove this inequality, we solve for in terms of and chosen independently by the victim and adversary respectively and initial reserves amounts ${\textsf{r}_{}}$. We exploit the constant reserve product invariant which holds throughout the execution.

Since is assumed in sub-case (b), the 3rd equation (back-run) yields

(6)

From the 2nd equation (victim swap), we solve for in terms of independent parameters , and ${\textsf{r}_{}}$

From the 1st equation (front-run) , so we can rewrite the above as

Substituting the RHS above for in the denominator expression of (6) and then substituting the RHS of (6) for in (5) yields

(7)

The attacker profit is positive but strictly less than the gain (4) obtained in sub-case (a).

Case 2 (successful sandwich & disabled victim swap): Should the victim swap not execute in round r, then can simply revert the state of the AMM with a back-run in the round $r+1$ with the same parameter values as in the front-run.

The attack execution is trivially cost-neutral for .

Case 3 (failed sandwich & enabled victim swap): We must show that the attacker front-run must be disabled assuming the attacker parameters are chosen as described in the attack strategy. Further, we can demonstrate that the back-run by the attacker is profitable.

As described in step (1) of attack strategy, ’s front-run parameters are chosen such that

(8)

Thus, the front-run swap is only enabled if the received amount is equal or greater to shown above. Note, that this doesn’t hold if the front-run is executed in state of case (3) following the enabled victim swap. We prove this by contradiction: assume that the front-run executes following the victim swap, then the constant reserve product invariant must hold.

We solve for in the first equation and insert into the second equation to obtain

Further, we solve for in terms of ${\textsf{r}_{}}$, and

Comparing with in (8), we can infer the following inequality

which cannot hold in a valid execution by definition of swaps: a user cannot receive less than the chosen swap limit. Thus, the front-run cannot be enabled in state of case (3).

Next, we prove the profitability of the back-run. Assuming a sufficient balance of the attacker to revert the effect of the victim swap, the swap parameters of the back-run can be chosen to reverse the affects of victim swap on the AMM reserves, which observes following the output-phase of round r: namely, and . We insert these into the reserve product invariant from the victim swap

to obtain

For equal unit value of both token types, this is clearly profitable, as receives more value () as it sends (). If attacker has no balance of it simply omits the back-run and the attack is aborted, resulting in a cost-neutral execution for the attacker.

Case 4 (failed sandwich & disabled victim swap): As in case (2) - should the victim swap not execute in round $\mathsf r$, then can simply revert the state of the AMM with a back-run in the round $\mathsf r+1$

The attack execution is trivially cost-neutral for .

D Speculative Sandwich with Private User Balances

Importantly, when performing the speculative AMM swap attack as shown in C, the direction of the victim swap must be known. If user balances are private, will have to guess the direction of the front-running swap. However, this is not a profitable strategy: an incorrect guess can result in a loss for as shown in the trivial example execution below.

Again, assuming equal unit value of and , realizes a loss of $7+15-21.5 = 0.5$. No back-run swap is possible that extracts any arbitrage value given that the reserve ratio is already consistent with the assumption that unit values of and are equal [4]. Thus, speculative sandwich attacks are only rational if the victim swap direction can be inferred, motivating the need for private user balances.

E Example: Speculative Sandwich of Scheduled Swap

We illustrate an example of a sandwich of a scheduled swap. Such an attack can be exploited despite the batching of blinded user inputs Sect. 3.2, as long as input schedules remain public. Let be a swap action that is scheduled to execute as soon as possible following block-chain round $\mathsf r$, thus requiring no further interaction from the user. Further, let the set of scheduled swap orders be captured in a publicly observable state fragment, i.e. . In practice, such a scheduled swap order will be evaluated prior to the first swap order in round $\textsf{r}+1$, so that it is not possible for the adversary to place a front-run swap before it in round $\textsf{r}+1$.

However, the sandwich attack can still be executed by an adversary which prevents honest users from submitting swap. The adversary simply submits the front-run to round $\mathsf r$, and the back-run to round $\mathsf r+1$, whilst suppressing all other user inputs.

We emphasize that scheduled swap orders do not require the submitting user to participate in the round it is scheduled: it is evaluated automatically by the application. Furthermore, since the victim’s swap parameters are public, the front-run and back-run parameters can be chosen to optimize ’s profit.

F Speculative Sandwich in Hash-Based Commit and Reveal Schemes

As shown in Appendix C, the speculative sandwich attack is rational as long as the direction of the victim swap is known. Hash-based commit & reveal schemes suffer from selective output by the adversary (Fig. 3), permitting a speculative attack to succeed even if the swap direction cannot be inferred from public user balances. Here the attacker simply commits two front-run swaps of opposing directions in the same round as the victim swap, whilst suppressing other user inputs. In the output-phase, the adversary learns the direction of the victim swap before having to open its own commitments and selectively opens the front-run of the same direction as the victim swap, whilst refraining from opening the other front-run swap. The back-run is then executed as in Appendix C.