In-depth exploration of Angle's oracle solution and how it is constructed to mitigate front-running trades.
Compiled by: DChain Community
A significant amount of research has been invested in the design of the Angle Protocol. While its structure may appear simple on the surface, there are many complex ideas behind it that need to be understood. In this series of articles, we will delve into some elements of the protocol and explain why they are designed this way.
The first article discusses Angle's oracle solution and how it is constructed to mitigate front-running trades.
Introduction
Angle allows users to mint and burn agTokens (stablecoins) in exchange for other tokens. Traders can also open long positions on available collateral/stablecoin pairs. These are not traditional perpetual contracts, as the equilibrium does not rely on funding rates, and the execution price comes directly from the oracle.
Given these use cases, the protocol needs a reliable way to price available assets to be able to quote users fair prices and protect itself from front-running trades. In the FAQ of this article, Samcszun explains why this is not simply a matter of using spot prices.
Front-running trades have been a long-standing issue in the market. It boils down to certain participants being able to access information earlier than others, allowing them to exploit this information to gain risk-free profits at the expense of the other party in the trade. Historically, preventing this phenomenon on-chain has been very difficult. The high costs and low speeds of Ethereum transactions make it challenging for oracles to update prices quickly and frequently. This introduces delays between on-chain and off-chain prices, enabling front-runners to profit from this.
Not all stablecoin protocols are concerned about the risks of front-running trades caused by oracle delays. In the case of Maker's DAI, oracle delays often benefit the protocol. If someone sees that her position will be liquidated due to a price drop in the next oracle update, she is incentivized to return funds to the vault, thereby improving the protocol's health and collateral ratio.
Synthetix, which allows for oracle value exchanges between synthetic assets and collateral, is a perfect example illustrating the dilemma of front-running trades faced by stablecoin protocols. Their blog post summarizes the long history of the protocol with front-running trades, including some attacks they have suffered in the past.
Similar to Synthetix, Angle allows asset exchanges without price slippage at the oracle value. Therefore, Angle also faces the same front-running trade issues. The core team of Angle has made significant efforts to prevent front-running trades. Two main improvements have been implemented in this regard: a specific oracle design and a dynamic fee structure. In this article, we will explain Angle's oracle design and the reasoning behind it.
Front-running trade on an oracle update: an example
Before delving into Angle's solution, let's first try to understand how front-running trades can harm the protocol. We will consider an example where ETH is accepted as collateral backing Angle's stablecoin.
Without transaction fees
Assume an attacker is looking at the off-chain ETH price and sees that the Chainlink oracle is about to update the on-chain data to a higher price (from p0 to p1, where p0 < p1). This attacker can send a transaction to burn x stablecoins at the price of p0, exchange it for x/p0 ETH, and then sell it back to the protocol after the price updates to p1, thus making a profit:
Due to this front-running trade on the oracle update, this portion of profit has been taken from the protocol's reserves. If we set x = 100ETH_ and p1 = 1.01 * p0 (price increases by 1%), this would mean the attacker has taken 1 ETH from the protocol's reserves.
With transaction fees
Fortunately, increasing transaction fees can mitigate this issue, as they erode the profits of front-runners and reduce opportunities.
For example, if the transaction fees for minting and burning are constant and equal to f, then an attacker who burns x stablecoins at p0 and sells ETH back to the protocol at p1 will ultimately see the following profit:
Compared to the previous case, the fees reduce the profit:
When the transaction fee is f=0.3% and following the above example, the attacker's profit is now only 0.39 ETH.
With transaction fees and two oracle solutions
To further reduce this opportunity, we can rely on a secondary oracle to obtain two possible price sources: pC (Chainlink price) and pU (Uniswap price). The protocol can utilize the most favorable price (the lower price when minting, i.e., buying the user's tokens, and the higher price when burning, i.e., selling ETH to the user), making the opportunity for front-running trades less attractive.
Imagine a trader trying to profit from the same opportunity as above, assuming pC0 < pC1.
On the other hand, we can consider pU to be constant and closer to pC0, thus:
We will see later that due to the design of Uniswap's time-weighted average price (TWAP), pU tends to lag behind pC.
- In this case, an attacker trying to profit from the potential opportunity will buy tokens from the protocol at pC0 (burning stablecoins), exchange for x(1-f)/pC0 ETH, and then sell it again at a higher price of pU1, resulting in a profit/loss of:
If we keep the numbers from the previous example, the attacker will ultimately lose 0.6 ETH in this operation.
Angle's Solution
Angle's design is specifically aimed at eliminating this front-running trade risk. Therefore, the protocol will implement a mechanism very similar to the example above. In this section, we will explore potential existing options in more detail, focusing on the specifics of the design we are going to implement and analyzing our choice of TWAP time window.
Options
The main oracle solutions that may fit Angle's use case include:
Chainlink
Uniswap V3 TWAP
Maker Feeds
Chainlink is the obvious first choice: it is a widely used decentralized oracle solution that provides multiple data sources covering various assets. Their prices come from multiple data sources and are relayed through a decentralized network, ensuring that this data is reliable, accessible, and difficult to manipulate. However, certain data sources typically only update after "significant" price changes (e.g., 0.5% for ETH/USD) or after a period of time, meaning Chainlink's prices are always lagging behind actual market prices. Therefore, Chainlink's price updates may be subject to front-running trades due to off-chain price observations or memory pools.
Uniswap V3 Time-Weighted Average Price (TWAP) is another obvious and widely used oracle solution. TWAP can be queried from Uniswap's contracts to obtain the time-weighted average price of tokens in the pool over a specific time period, ranging from a few seconds to 9 days. The price is calculated based on the average price between the two tokens over the specified time. With this, manipulating TWAP requires significant capital and takes a long time, which is inefficient in most cases.
Nevertheless, since TWAP is the average price of past blocks observed, they tend to lag behind even the real-time off-chain prices or Chainlink price sources. If used alone, they are insufficient to protect the protocol from front-running trades.
Additionally, since TWAP only reports the price of on-chain token pairs, they cannot meet the protocol's goal of providing access to assets that are not represented on-chain (and thus not in the Uniswap pool), such as foreign exchange stablecoins.
Using Maker Oracles could have been another option for Angle. However, this means trusting MakerDAO and going through a governance process to access price data. The price sources are also limited to those used by Maker, which is not sufficient for us as we want access to foreign exchange rates.
Angle's Design: Chainlink + UniV3 TWAP
Given this, it was decided to combine Angle Protocol's Chainlink oracle with a 10-minute Uni V3 TWAP. This allows for obtaining the fairest possible price at any time while protecting the protocol from front-running attacks.
In general, Angle's contracts will compare prices from both channels and use the price that is most favorable to the protocol. With this design, front-running the protocol becomes more complex, as manipulating or front-running two oracles is necessary to exploit the protocol's exchange rate.
Specifically, our contracts will obtain the best prices for all volatile asset/stablecoin pairs between Chainlink and Uniswap, using Chainlink's forex oracle to convert the prices into the desired fiat currency. Each collateral/stablecoin pair will have a dedicated oracle contract and its independent price source.
How does it work?
For example, suppose a user wants to trade on the ETH/agEUR pair. Our contract needs to obtain the prices for ETH/USD and USD/EUR. It will retain the best price for ETH/USD from Chainlink and the 10-minute TWAP from the ETH/USDC UniV3 pool. Then, it will fetch the forex price for USD/EUR from Chainlink.
Example: Uniswap ETH/USDC TWAP: 1900 USD (the protocol assumes that USDC typically maintains its peg, i.e., 1 USDC is worth 1 USD); Chainlink ETH price: 1850 USD; Chainlink USD price: 1.16 EUR. If the user wants to mint agEUR in this case, the protocol will use the lower ETH/USD price it can find, which is Chainlink's price of 1850 USD per ETH. Conversely, if in the same situation the user wants to burn agEUR for wETH, the protocol will use the higher price, which is the Uni ETH/USDC TWAP of 1900. In both cases, the protocol will convert ETH/USD to ETH/EUR using Chainlink's USD/EUR exchange rate of 1.16. Similarly, the protocol will use the highest price for users wishing to open perpetual contracts and the lowest price for those wishing to close contracts.
More generally:
User contracts that require prices will call the relevant oracle contracts.
Depending on the type, the oracle contracts can read quotes from UniV3 TWAP and Chainlink, or only from Chainlink (e.g., for stablecoin-to-stablecoin exchanges), and return them to the main contract.
Based on the operation being executed (minting, burning, opening, or closing), the relevant contracts retain the best quotes for the protocol and execute the trades.
Choosing the Uni V3 TWAP Time Window
Angle contracts will use a 10-minute time window for TWAP. This choice has been made with careful consideration, as different time windows can lead to drastically different price structures.
Differences Between Time Windows
In the case of Angle, on one hand, the time window should be sufficiently long to provide enough lag between the protocol and the spot prices. This indeed allows for a higher spread between minting and burning prices in the case of price volatility, especially when the risk of front-running from Chainlink doubles. Additionally, the longer the time window, the harder it is to manipulate the TWAP price, as the impact of recent observations on the price diminishes.
On the other hand, the protocol should still provide users with fair and up-to-date quotes: using a time window that is too wide will create too large a price gap between us and the current market price, while using a time window that is too narrow will not give us the desired price difference.
Comparing 10-Minute and 60-Minute TWAP with Chainlink Price Sources
To give you an understanding of why we ultimately chose a 10-minute time window, below is a comparison of the 10-minute and 60-minute ETH/USDC TWAP with Chainlink ETH/USD prices and Coinbase closing prices.
You can see how the protocol uses the upper and lower rates during transitions between prices when users mint/close and burn/open, moving between the most favorable prices of Chainlink and Uniswap's TWAP.
While the 60-minute TWAP blocks often give prices far from the market, the 10-minute TWAP provides a beneficial buffer for Chainlink's price source, keeping prices sufficiently close to the market.
It is worth noting that from the first chart, the higher the volatility, the larger the spread between Chainlink and Uniswap prices. Conversely, when prices remain relatively stable over a period, the price sources from Uniswap and Chainlink converge.
Using TWAP as an additional protection against front-running effectively amounts to dynamically charging more significant fees during periods of high price volatility, as the risk of front-running is greater due to on-chain oracle delays. The cost of these higher effective fees is a reduced ability for arbitrage traders to reprice stablecoins directly from the protocol.
In most cases, the prices from Uniswap and Chainlink will be very similar, making it almost imperceptible for users that two oracle solutions are being used. During periods of high volatility, when the protocol may be front-run due to significant price discrepancies between current and future Chainlink on-chain prices, the protocol prices will differ, providing protection against front-running.
Focus on Synthetix Fee Recovery/Refund
Angle's oracle research has been greatly inspired by Synthetix's governance discussions on front-running and related blog posts. In our research, we also encountered another option they implemented in February 2020, which was fee recovery/refund, a solution that ultimately proved to be temporary.
What they did was add a waiting period for trades during which users could not manipulate the Synth they wanted to use. During this period, the oracle could check whether the trade was affected by inconsistencies, i.e., whether there was a price difference between the execution time and the end of the waiting period. If there was, the price difference had to be paid by either the user or the protocol to the other party (the protocol or the user), or paid in the next trade with Synthetix.
This solution was very effective in reducing front-running trades, but they had to extend the waiting time and increase fees, which created a very poor user experience for all traders. It also hindered the combination of Synth with other protocols in many use cases. In SIP-120, they replaced this solution with a scheme that adds the use of TWAP oracles for large trades.
Conclusion
Angle's specific oracle design has two main impacts on the protocol:
Attackers need to manipulate two markets to deceive the protocol, significantly reducing the risk of successful front-running trades.
During periods of market pressure, the protocol is less likely to quote users the best prices.
The latter impact has been discussed in the governance forum of Fei. Since providing the best trade execution is not the core goal of the protocol, we believe that resistance to front-running trades is more important to ensure the protocol's security. Secondary markets will provide better trade execution during high volatility.
Our goal in the Angle project is to design a fully supported and efficient stablecoin protocol. Achieving this requires considering many aspects of the protocol to ensure it cannot be deceived into an unfavorable position, one of which is resistance to front-running trades. This is particularly important because the stability of on-chain decentralized stablecoins that rely on oracles depends on their oracles.
Adding secondary price feeds in the form of TWAP can help the protocol mitigate the potential adverse effects of high market volatility and the front-running opportunities that arise during these moments.
Finally, it is important to note that this oracle solution maintains flexibility and scalability. On one hand, Angle governance can vote at any time to update its oracle contracts. On the other hand, oracles can be created for any price feed supported by Chainlink. This is the minimum support needed to realize Angle's vision of bringing financial assets on-chain in a capital-efficient manner.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
