This third article intends to explain how with HAs able to open high leverage positions, the protocol is still front-running resistant thanks to its fee structure.

In our previous research articles, we introduced our oracle solution to show how it could prevent front-running, and we tried to show how fees could help mitigate the front-running problem for users minting and burning stablecoins.

The reason why we dwelled on it is that front-running is a long-standing issue in markets. It comes down to the fact that some actors have access to information before others, which they can leverage to make risk-free profits at the expenses of the other side of the trade. Historically, this has been very difficult to prevent on-chain. The high cost and low speed of transactions on Ethereum makes it difficult for oracles to update prices quickly and frequently. This introduces discrepancy between off-chain and on-chain prices, which can be turned into a risk-free profit by front-runners emptying the protocol reserves on the way.

In the case of Angle’s Hedging Agents, the threat is even more important than that of users minting and burning stablecoins, as they can use leverage to multiply their profit (and hence the protocol’s losses) coming out of these front-running opportunities.

To protect the protocol from this risk, multiple mechanisms need to be put in place, including minimum transaction fees. We will look into the maths of the problem, and explain the rationale of the solution we have designed. We hope to leave you with a better understanding of why we need to charge these entry and exit fees to Hedging Agents and why we compute the fees for HAs the way we do. Let’s dive into it!

When looking at this problem, we want to find out how entry and exit fees can affect the potential profit coming from these opportunities, and how margin, position size, and leverage play a role. This will indicate where we should charge those fees, and how high they should be.

For the rest of the article we will use the following variables:

• Initial margin before fees (or amount brought): x

• Position size (or amount committed): y

• Max leverage: M+1 (leverage is computed within Angle as (margin+position size)/margin and not position size/margin)

• Profit: y * (1 — initial price/current price)

• Oracle rate at time t0: normalized for simplicity to 1

• Oracle rate at time t1 : 1 + k, this represents an increase of k% of the price from t0

• Entry fees: fe

• Exit fees: fs

A HA within Angle can do 4 different types of action: open a position, add collateral to a position (increase margin), remove collateral from a position (decrease margin), close a position. To begin, let us first write the state of a HA perpetual after each type of action:

Open position at time t0: Fees are charged on the position size (similar to Perp protocol and traditional crypto exchanges). We will try to prove how taking fees on the position size rather than on the margin could protect from front-running. Entry fees are noted fe.

• Margin: x — y * fe

• Position size: y

• Initial rate: 1

Add to margin at time t0: No fees are taken by the protocol for this action as it doesn’t affect the position size but only the margin and liquidation ratio → no risk of front-running.

• Margin: x — y * fe + amount added to margin

• Position size: y

• Initial rate: 1

Remove from margin at time t0: No fees are taken by the protocol for this action as it doesn’t affect the position size but only the margin and liquidation ratio

• Margin: x — y * fe + amount removed from margin

• Position size: y

• Initial rate: 1

Close position at time t1: When a HA cashes out a perpetual, fees are charged on the position size. We note this fees fs. The cash out amount of the HA is in this case

!https://miro.medium.com/max/1350/1*kqDJ1o19wNy0SaFgN2EKbQ.png

With that in mind, we want to figure out in what conditions traders (HAs) can successfully front-run the protocol. Suppose a HA knows that at time t1 price will be 1+k. Then the optimal thing to do will be to open a perp with a maximum leverage to profit from this increase in price.

At time t0: The HA opens a perp with maximum leverage (as the goal is to optimize future returns)

• Initial margin: x — Mxfe

• Position size: M * x

• Initial oracle rate: 1

At time t1: the oracle is updated to the HA expected value which is an increase of k%. She decides to close the perp and receives here initial margin plus the profit from the price increase minus the open and close fees (fe and fs) paid:

!https://miro.medium.com/max/1382/1*QHjOwJZODdpIPgk_DHscAA.png

To understand if we are front-running proof, we need to find the fees for which this strategy would be profitable. This is the case when the cash out amount (equation above) is greater than the initial margin. As such, we get:

!https://miro.medium.com/max/1356/1*mexh5oCNdN8BiGWGGhzICg.png

From this equation, we can conclude that the protocol is likely to be front-ran if the sum of transaction fees is less than the price discrepancy that can be leveraged. In other words, fees need to be above this discrepancy for the protocol to be fully resistant. These are great conditions on fees, as they neither depend on the position size nor the initial margin!

Now, let’s look at an example. We suppose that the insider info is k = 0.2% (this could be the Chainlink deviation threshold), and that the fees are fixed and equal such that f = fe = fs. Then, to be resistant to front-running, the protocol needs to set fees such that:

!https://miro.medium.com/max/1312/1*ESQtx1Eefk3txX3rsuXWTg.png

In the example’s situation, we would need to charge fees of at least 0.1%.

This is consistent with our approach for Chainlink price feeds: if we know that we have a lag on prices equivalent to Chainlink’s deviation threshold, then we need charge entry and exit fees according to formula (9) to nullify front-running.

Doing this research helped us better understand the front-running threats we were facing against HA perpetual positions. Finding this solution allows us to fix entry and exit fees high enough for the protocol to be sustainable.

Combined with our oracle solution, the protocol is robust enough to be resistant to front-running attacks, even with HAs able to open up to 100x leverage positions.

To mitigate even more front-running issues, we implement an additional measure in the protocol. After being opened, perpetuals are locked for a pre-determined amount of time before the owner is able to decrease margin or close position. The reason for putting a lock is that it contributes to adding some stochasticity on the price for HAs: a HA may have an insider advantage for a price update supposed to occur in like 10 minutes, but with a lock of 1 hour, the HA is less likely to know what the price is going to be at the time at which it will be able to close the position.

Note here that we have found the floor fees for the protocol to be protected against front-running. In the protocol, fees are going to dynamically depend on a quantity called the hedge ratio that is how much of the protocol’s collateral is hedged by HAs. We will explain the logic for this in a future article.