This second article deals with Angle’s minting and burning fees, and how they are necessary to avoid front-running attacks.

Front-running because of on-chain oracle latency is one of the biggest risks that the protocol faces. In our previous article about Oracles and front-running in Angle, we saw how Angle’s oracle design solution helped mitigate this problem. Yet, this is not the panacea.

On top of reliable oracles, the protocol need fees to reduce this risk. Setting them correctly is very important to make the protocol sustainable. With too low transaction fees, Angle would be vulnerable to these attacks, but with too high fees, interacting with the protocol would be unsustainable for users.

The reason there are front-running risks in the first place is because of the oracle latency problem. Since Ethereum transactions are costly and the average block time is 13sec, oracles, like Chainlink, cannot update their prices in real-time to track off-chain evolutions. Because of that, Chainlink introduces both a time and a price deviation threshold for each of its oracle feeds that, if passed, trigger an on-chain price update.

This price deviation threshold is what can be used by traders to front-run the protocol and take risk-free profit out of its reserves. A highly hypothetical example would be that someone looking at a pair with a 1% deviation threshold and witnessing a price discrepancy of 1% before it is updated on-chain. This person could profit by buying at the outdated price, and wait for the Chainlink on-chain price to update to sell for a profit.

In the situation above, it is assumed that only one collateral is involved in the arbitrage (DAI for example). However, as Angle allows multiple collaterals to back a single stablecoin, the problem is a bit more complex and fees are harder to optimize. More complex arbitrage could be put in place by attackers minting stablecoins using one collateral and burning these stablecoins for another collateral type.

Below, we explore what transaction fees need to be set to be protected from front-running in the case of a stablecoin pegged to USD (agUSD) backed by 2 collateral types and using a single oracle solution (Chainlink) with its own set of deviation thresholds. The solution derived generalizes to a stablecoin pegged by n different collaterals.

• 2 collateral types : USDC and DAI

• DAI: Chainlink Deviation threshold is kDAI%

• USDC: Chainlink Deviation threshold is kUSDC%

• At time t0: 1 USDC is worth 1 DAI that is worth 1 USD

• At time t1: the lagged prices are updated on Chainlink, such that if the dev. threshold is k%, and there is a drop in USDC price of k%, then, at time t1, 1 USDC is worth (1-k) USD

• We explore here two different situations (A and B)

• 

Situation B: 1 DAI is now worth (1+k.\text{DAI}) \text{USDC} on-chain. We consider here that the price of USDC increases by k.\text{USDC}. Following the increase in price, an arbitrageur could take the opportunity to mint back her agUSD by burning collateral and receive:

Situation A: Arbitrage (mint then burn) is profitable if:

Situation B: Arbitrage (burn then mint) is profitable if:

From the example of the arbitrage opportunity section above, we see that the inequalities that need to hold to make the arbitrage opportunity null and protect the protocol in all situations are:

From the example of the arbitrage opportunity section above, we see that the inequalities that need to hold to make the arbitrage opportunity null and protect the protocol in all situations are:

But as

If the protocol is covered for the case where both prices decrease simultaneously, it is also covered for the case where prices evolve in different directions.

Back to the system (5), we can see that the inequalities $a$ and $c$ are redundant. Indeed if $a$ is verified, c will be as well as $1-k\text{DAI}\leq\frac{1}{1+k\text{DAI}}$:

Similarly, inequalities b and d are redundant as well. Therefore, we can discard c and d from the equations such that the remaining conditions are:

This must hold true for every pairs on a single stablecoin pool.

To solve these inequalities, we need to break up the minting and burning fees. Let’s say that for $x$ and $y$ some positive real values, we set the fees as:

such that the fees represent a share of the deviation thresholds, depending on the value of x and y. Then the conditions become:

Finding the smallest transaction fees for the protocol comes down to finding the smallest $x$ and $y$ such that the equations hold true. We can then derive the minting and burning fees from $x$, $y$, and the pair deviation threshold kCollat.

From the the first line, we see that $x+y ≥1$ is not enough. The second one shows that we can optimize x and y by making the condition hold for the “worst” pair. In this case, if both equations are verified for all pairs and their respective deviation thresholds kCollat, there wouldn’t be any internal arbitrage opportunity.

Unfortunately, if another protocol with more up-to-date prices than Chainlink feed is involved in the transaction, optimizing our parameters x and y is not possible anymore. In this case, traders could capture the remaining spread between our prices at $t_0$ and their more up-to-date prices.

Because of that, the protocol needs to set $x = y = 1$ to protect itself from front-running, such that, from equation (4), minting and burning fees need to verify:

If there is more than one read to Chainlink in the circuit (sequence of oracle reads) then the deviation threshold will be compounded. Suppose a two parts circuit (ETH/USD + USD/EUR for example), with $k_1$ the deviation threshold for the first pair and $k_2$ for the second one. The final deviation threshold would be:

One of the essential goal when building a protocol like Angle is robustness and sustainability. As such, being front-running resistant is very important to maintain the protocol’s health.

The study of the different ways with which fees could be set up to make sure front-running oracle latency opportunities are neutralized shows that we cannot do much better than charging fees at least as important as oracles deviation threshold to mint and burn agTokens.

The problem is that for some pairs deviation thresholds are sometimes too big (like 2% for DAI/USD) to be used in production by users. Two remarks:

• This doesn’t really matter for pairs like DAI/USD, as this type of deviation is almost never observed and setting 2% fees to be covered for a situation that happens only 0.001% of the time would be disproportionate.

• Angle does not rely on a single oracle solution: by using a 10min Uniswap TWAP on top of Chainlink for pairs with high volatility or an important deviation threshold, Angle manages to be front-running resistant without even having to set fees equal to the deviation threshold. Our first research article has an example of how combining fees with deviation threshold mitigates front-running and so with our oracle solution we can relax the condition around the fees being equal to the deviation threshold.