Oracle and frontrunning transactions
TechFlow Selected TechFlow Selected
Oracle and frontrunning transactions
A deep dive into Angle's oracle solution and how it is designed to mitigate frontrunning transactions.
Navigating Web3 tides with focused insightsCompiled by: Denling Community
A significant amount of research has gone into the design of Angle Protocol. While its structure may appear simple on the surface, there are many complex concepts 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 were designed this way.
The first article discusses Angle's oracle solution and how it is constructed to mitigate frontrunning.
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 equilibrium does not rely on funding rates, and execution prices come directly from oracles.
Given these use cases, the protocol needs a reliable way to price available assets so it can quote fair prices to users and protect itself from frontrunning. In an FAQ in this article, Samczun explains why this is not simply a matter of using spot prices.
Frontrunning is a long-standing issue in markets. It boils down to certain participants gaining access to information earlier than others, enabling them to extract risk-free profits at the expense of counterparties taking on risk. Historically, preventing this on-chain has been very difficult. The high cost and low speed of Ethereum transactions make it hard for oracles to update prices quickly and frequently. This introduces latency between off-chain and on-chain prices, allowing frontrunners to exploit the gap for profit.
Not all stablecoin protocols are concerned about frontrunning risks introduced by oracle delays. In the case of Maker's DAI, oracle delays are typically beneficial to the protocol. If someone sees her position will be liquidated at the next oracle update due to a price drop, she is incentivized to deposit more funds into the vault, thereby improving the protocol’s health and collateral ratio.
Synthetix, which allows value exchanges between synthetic assets and collateral at oracle prices without price slippage, is a perfect example of a stablecoin protocol facing frontrunning challenges. Their blog posts summarize the protocol’s long history with frontrunning, including several attacks they have suffered in the past.
Like Synthetix, Angle allows asset exchanges at oracle values with no price slippage. Therefore, Angle also faces the same frontrunning issues. The Angle core team has invested substantial effort into preventing frontrunning. Two major 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.
Frontrunning an Oracle Update: An Example
Before diving into Angle’s solution, let us first understand how frontrunning can harm the protocol. We will consider an example where ETH is accepted as collateral backing an Angle stablecoin.
No Transaction Fees
Suppose an attacker monitors the off-chain ETH price and observes that the Chainlink oracle is about to update the on-chain data at a higher price (from p0 to p1, where p0 < p1). This attacker can send a transaction to burn x stablecoins at price p0, receiving x/p0 ETH, then sell it back to the protocol after the price updates to p1, thus making a profit:
Due to frontrunning this oracle update, this profit has been extracted from the protocol’s reserves. If we set x = 100 ETH and p1 = 1.01 * p0 (a 1% price increase), this means the attacker has taken 1 ETH from the protocol’s reserves.
With Transaction Fees
Happily, adding transaction fees can mitigate this issue, as they erode frontrunners’ profits and reduce opportunities.
For instance, if the minting and burning transaction fees are constant and equal at f, then an attacker who burns x stablecoins at p0 and resells the ETH back to the protocol at p1 ends up with the following profit:
Compared to the previous case, 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 Dual Oracle Solution
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 use the most favorable price (the lower price when minting—buying tokens from users—and the higher price when burning—selling ETH to users), making frontrunning less attractive.
-
Imagine a trader trying to profit from the same opportunity described above, assuming pC0 < pC1.
-
On the other hand, we can assume pU is constant and closer to pC0, so:
We will later see that due to the design of Uniswap’s time-weighted average price (TWAP), pU tends to lag behind pC.
-
In this scenario, an attacker attempting to profit from the potential opportunity would buy tokens from the protocol at pC0 (burning stablecoins), receiving x(1-f)/pC0 ETH, and resell it at pU1 at a higher price, resulting in the following P&L:
If we keep the numerical values from the previous example, the attacker would end up losing 0.6 ETH in this operation.
Angle’s Solution
Angle is specifically designed to eliminate this frontrunning risk. Therefore, the protocol implements a mechanism very similar to the one described above. In this section, we will explore in greater detail the potential oracle options, focus on the specifics of our chosen design, and analyze our selection of the TWAP time window.
Options
The main oracle solutions potentially suitable for Angle’s use case are:
-
Chainlink
-
Uniswap V3 TWAP
-
Maker Feeds
Chainlink is the obvious first choice: it is a widely used decentralized oracle solution providing multiple data sources across various assets. Its prices come from multiple off-chain sources and are relayed via a decentralized network, ensuring reliability, accessibility, and resistance to manipulation. However, certain data sources typically update only after “significant” price changes (e.g., 0.5% for ETH/USD) or after a time interval, meaning Chainlink prices always lag behind actual market prices. As a result, Chainlink price updates can be frontran by monitoring off-chain prices or the mempool.
Uniswap V3 Time-Weighted Average Price (TWAP) is another widely adopted oracle solution. TWAP can be queried from Uniswap’s contract to obtain the time-weighted average price of token pairs within a pool over a specified period, ranging from seconds to nine days. The price is calculated as the average of the price between the two tokens over the designated time. Manipulating a TWAP requires substantial capital and sustained effort over time, making it inefficient in most cases.
Nevertheless, because TWAP represents the average price observed over past blocks, it tends to lag behind real-time off-chain prices and even Chainlink sources. If used alone, it is insufficient to protect the protocol from frontrunning.
Additionally, since TWAP only reports prices for on-chain token pairs, it cannot fulfill the protocol’s goal of providing access to assets not represented on-chain (and thus not in Uniswap pools), such as forex-backed stablecoins.
Using Maker Oracles could have been another option for Angle. But this would require trusting MakerDAO and going through a governance process to gain access to price data. The available price sources would also be limited to those used by Maker, which is insufficient for our needs, as we aim to access foreign exchange rates.
Angle’s Design: Chainlink + UniV3 TWAP
Taking these factors into account, it was decided to combine Angle Protocol’s Chainlink oracle with a 10-minute UniV3 TWAP. This enables access to the fairest possible price at any time while protecting the protocol from frontrunning attacks.
In general, Angle’s contracts compare prices from both channels and use the one most favorable to the protocol. With this design, frontrunning becomes significantly more complex, as attackers must manipulate or frontrun two oracles simultaneously to exploit the protocol’s exchange rate.
Specifically, our contracts retrieve the best price across all volatile asset/stablecoin pairs from both Chainlink and Uniswap, and use Chainlink’s forex oracles to convert prices into the desired fiat currency. Each collateral/stablecoin pair will have a dedicated oracle contract with independent price sources.
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 take the best ETH/USD price from Chainlink and the 10-minute TWAP from the ETH/USDC UniV3 pool. Then, it will fetch the USD/EUR forex rate from Chainlink.
Example: Uniswap ETH/USDC TWAP: 1900 USD (the protocol assumes USDC typically maintains its peg, i.e., 1 USDC = 1 USD); Chainlink ETH price: 1850 USD; Chainlink USD price: 1.16 EUR. If a user wants to mint agEUR under these conditions, the protocol will use the lower ETH/USD price available, i.e., Chainlink’s 1850 USD per ETH. Conversely, if under the same conditions the user wants to burn agEUR for wETH, the protocol will use the higher price, i.e., the Uni ETH/USDC TWAP of 1900. In both cases, the protocol will use Chainlink’s USD/EUR exchange rate of 1.16 to convert ETH/USD into ETH/EUR. Similarly, the protocol will use the highest price for users wishing to open a perpetual position and the lowest price for those wishing to close it.
More generally:
-
The user contract requiring a price calls the relevant oracle contract.
-
Depending on the pair type, the oracle contract reads quotes from either UniV3 TWAP and Chainlink, or only Chainlink (e.g., for stablecoin-to-stablecoin swaps), and returns the price to the main contract.
-
Based on the operation being performed (minting, burning, opening, or closing), the relevant contract retains the best price for the protocol and executes the transaction.
Selecting the UniV3 TWAP Time Window
Angle contracts will use a 10-minute time window for TWAP. This choice was carefully considered, as different time windows can lead to vastly different price structures.
Differences Between Time Windows
In Angle’s case, on one hand, the time window should be sufficiently long to provide adequate lag between the protocol and spot prices. This indeed allows for wider spreads between minting and burning prices during price volatility, especially when Chainlink’s frontrunning risk is doubled. Moreover, the longer the time window, the harder it is to manipulate the TWAP price, as recent observations have less impact on the overall average.
On the other hand, the protocol should still offer users fair and up-to-date pricing: too wide a time window creates excessive gaps from current market prices, while too narrow a window fails to provide the desired price differential.
Comparing 10-Minute and 60-Minute TWAPs Against Chainlink
To illustrate why we ultimately chose a 10-minute time window, below we show comparisons of 10-minute and 60-minute ETH/USDC TWAPs against Chainlink ETH/USD prices and Coinbase closing prices.
You can see how, during price transitions, the upper and lower bounds used by the protocol for user minting/closing and burning/opening shift between the most favorable prices from Chainlink and Uniswap TWAPs.
While 60-minute TWAP segments tend to give prices far from the market, the 10-minute TWAP provides a beneficial buffer against Chainlink’s price feed while keeping prices sufficiently close to the market.
Notably, from the first chart, we observe that higher volatility leads to larger spreads between Chainlink and Uniswap prices. Conversely, when prices remain relatively stable over time, Uniswap and Chainlink price feeds converge.
Using TWAP as an additional protection against frontrunning effectively amounts to dynamically charging higher effective fees during periods of high volatility, when frontrunning risk is greater due to on-chain oracle latency. The trade-off is reduced ability for arbitrageurs to immediately rebalance the stablecoin price directly through the protocol.
In most cases, Uniswap and Chainlink prices will be very similar, making users barely notice the use of dual oracle solutions. During high-volatility periods, when the protocol might otherwise be frontran due to significant differences between current and future Chainlink on-chain prices, the protocol prices will diverge, protecting the system from exploitation.
Looking at Synthetix Fee Reclaim / Rebate
Angle’s oracle research has been heavily inspired by Synthetix’s governance discussions on frontrunning and their related blog posts. In our research, we also encountered another option they implemented in February 2020: fee reclaim / rebate, which eventually proved temporary.
What they did was introduce a waiting period for trades, during which users could not alter the Synth they intended to trade. During this time, the oracle could check whether the trade was inconsistent, i.e., whether there was a price difference between execution time and the end of the waiting period. If so, the price difference had to be paid by either the user or the protocol to the other party, or settled in the next trade with Synthetix.
This solution was highly effective in reducing frontrunning, but they had to extend wait times and increase fees, resulting in a very poor user experience for all traders. It also prevented Synths from being composable with other protocols in many use cases. In SIP-120, they replaced this solution with one that uses TWAP oracles for large trades.
Conclusion
Angle’s specific oracle design has two major impacts on the protocol:
-
An attacker must manipulate two markets to deceive the protocol, greatly reducing the risk of successful frontrunning.
-
During periods of market stress, the protocol likely won’t offer users the best available price.
The latter effect is an issue discussed in Fei’s governance forum. Since offering optimal trade execution is not the protocol’s core objective, we believe frontrunning resistance is more important to ensure protocol security. Secondary markets will provide better execution during high volatility.
Our goal with Angle is to design a fully backed, capital-efficient stablecoin protocol. Achieving this requires careful consideration of many aspects of the protocol to ensure it cannot be exploited to its detriment—one of which is frontrunning resistance. This is particularly crucial because the stability of on-chain, oracle-dependent decentralized stablecoins hinges on the integrity of their oracles.
Adding a secondary price feed in the form of TWAP helps the protocol mitigate the adverse effects of high market volatility and the associated frontrunning opportunities.
Finally, it should be noted that this oracle solution remains flexible and scalable. On one hand, Angle governance can vote at any time to update oracle contracts. On the other, oracles can be created for any price feed supported by Chainlink. This provides minimal yet sufficient support to realize Angle’s vision of bringing financial assets on-chain in a capital-efficient manner.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@UpchainDAO
