The article discusses the risks of using Uniswap V3 TWAP price oracles in lending protocols, particularly for long tail assets. These oracles can be manipulated, resulting in significant losses. To mitigate risks, protocols can use alternative oracles and consider factors like Uniswap volume and liquidity spread.
Safeguarding Long Tail Assets on Lending Protocols from TWAP Oracle Attacks
Most lending protocol hacks stem from smart contract vulnerabilities, resulting in hundreds of millions of dollars stolen every year. Developers and auditors have grown more cautious to common attacks, while protocols undergo multiple rounds of code reviews and bug bounty programs. However, lending protocols also face economic attacks as a result of market volatility and pricing issues such as de-peg events and oracle manipulation.
To prevent these attacks, most protocols list only highly liquid assets and utilize the most reliant oracle providers, primarily Chainlink. While most lending protocols don’t use decentralized exchange time-weighted average price (TWAP) oracles, they are one of the most accessible options. However, most protocols haven’t been able to find a secure methodology to safely use these oracles alone, as it's typically too risky compared to the alternatives.
Uniswap V3 TWAP price oracles have been used in lending protocols such as Inverse Finance, Rari Capital and Euler Finance. Although Uniswap and its V3 oracles are repeatedly referred to throughout the report, other TWAP oracles could function similarly. These oracles have a number of advantages, such as being free to integrate into protocols and less reliant on centralized controls, but the disadvantages prevent widespread use.
There are plenty of examples where oracles have been manipulated, especially TWAP oracles, along with research detailing why these attacks happen. Typically, it’s problematic when liquidity is inadequate at the oracle source, such as a Uniswap pool, leaving lending protocols that utilize the oracle for prices at risk of an attack.
The Euler Finance team wrote reports, including , and released an oracle attack to quantify risks of lending protocols using Uniswap V3 TWAP price oracles. Part of the focus in the report is to analyze spot price manipulation for at least one block. This consideration is also given to the Euler Oracle Tool simulator, shown in Figure 1 below, as it displays the values and costs per block up to ten blocks in the generated reports.
Attackers will try to limit the risk of failure by using a flash loan to complete the attack within one block. Although flash loans enable attackers to utilize more liquidity than they might have, the flash loans are unlikely to succeed on the most liquid assets within one block.
For example, Figure 1 below shows the total cost ($598.85 billion) to perform a one block attack for a 20% price impact on the USDC/WETH 0.3% fee pair. Due to lending restrictions, such as borrow and collateral factors (LTV ratio), attackers would typically need to pump or dump prices well beyond 20% to achieve a profitable attack.
Conditions to Manipulate Price Oracles
Minimizing the number of blocks to carry out an attack is essential for two reasons. Firstly, attackers utilize flash loans which need to be repaid within the same block. Secondly, the more blocks that occur increase the chances of the attacker getting arbitraged, which would terminate the attack as traders would see the price difference and make a trade to return the price to normal before the attack can be completed.
The most utilized assets such as USDC, USDT, and WETH are typically liquid enough to prevent a TWAP oracle manipulation attack, particularly for flash loans. This is more apparent on Ethereum mainnet as most layer two and other chains have comparably less liquidity. Lending protocols will typically use Chainlink price oracles for blue chip assets anyway, as it is well worth the cost to protect these assets, which are most often set as collateral assets.
Even if the most liquid pools don't have sufficient liquidity, there are numerous other pools on Uniswap, and other DEXs, that present instant arbitrage opportunities. The difference in price between two highly liquid tokens in different pools will be corrected by traders manually finding the arbitrage opportunity, bots, aggregators, or most likely by Uniswap’s .
The Auto Router will find the best price available by splitting trades across multiple pools. This means that if an attacker found a lending pool with substantial deposits that used a low volume, low liquidity pool on Uniswap V3 as its oracle, the attack could still fail if the other pools for the same token had high volume and liquidity because the next trade by the Auto Router would utilize the arbitrage opportunity. It’s even more difficult for the attack to succeed since the Auto Router can also split across routes of other unrelated tokens.
Similar assumptions may also be made about low liquid, high volume pools as well. With low liquidity, the pool’s oracle can be a vulnerable target. However, due to significant volume, the trades will constantly adjust the price to the market rate. Therefore, it can be unlikely for an attack to succeed.
An attacker would also need to consider liquidity spread on Uniswap V3, as Liquidity Providers can provide full range liquidity or concentrated liquidity. Full range liquidity, which adds tokens on both sides for the full price range from zero to infinity, increases costs of an attack. Concentrated liquidity, a specific range which can be only one-sided, can increase or decrease the costs depending on the current price and allocation of liquidity within the range. Wonderland's CTO 0xGorilla goes into further details about this in their article .
A 'safe' Uniswap pool does not need to have billions of dollars’ worth of tokens spread across a full range for the price oracle to be safe. Consider Figure 1 above, where it cost $598.85 billion to move the price 20% in one block, and it would still cost nearly $200 million across ten blocks. This pool has nearly $70 million in total value locked. However, this pool's spread is not purely in full range, as much of the liquidity is concentrated, which can increase risk.
The Euler oracle tool can also show that $10 million will move the price nearly 14% downwards at a cost of $1 million and nearly 56% upwards at a cost of $1.7 million for this pool. This would be potentially concerning for use as an oracle, but this 0.3% pool probably wouldn’t be the main pool used in lending protocols as the 0.05% fee pool contains $129 million in TVL and $2.4 billion in 7-day volume, according to Uniswap's data.
Liquidity Profiles
Users should take note of different liquidity spread profiles to better understand the risks of depositing on lending protocols that utilize Uniswap V3 TWAP price oracles. The graphs in Figure 2 demonstrate various liquidity profiles a user might find in Uniswap pools.
Graph LP 1 below shows a liquidity profile often assumed of Uniswap V3 pools. Liquidity (L) is generally concentrated around the current price (P) but tapers off further away in each direction of the two tokens, Token01 and Token02.
LP 2 demonstrates a typical stablecoin pair profile, such as USDC/USDT, where liquidity is extremely concentrated to several ticks around the current price.
LP 3 displays what a full range pool could look like without concentrated ticks of liquidity.
The liquidity in LP 4 is concentrated on the Token01 side of the current price, making it expensive to dump but cheaper to pump, while LP 5 shows the opposite.
If the lending protocol allows both tokens as collateral, then the attacker can choose to pump or dump to whatever direction is less costly and more profitable. If one asset is isolated, and cannot be used as collateral, then the attacker can only dump it to profit. There are other ways to profit from pumping an isolated asset, but it may be more complex, costly, or risky compared to simply dumping an isolated asset in an oracle attack or relying on other types of exploit methodology.
LP 6 shows this in action, as it would be less costly to dump the token from the old price (P1) at Point A to the new price (P0) at Point B.
Users need to be aware of liquidity levels, spread, and transaction volume if a lending protocol uses Uniswap V3 TWAP price oracles for its pools. A highly vulnerable Uniswap pool for an attacker would have low liquidity, low volume, liquidity concentrated away from the target price and the current price, and no other pools on Uniswap and other DEXs, or at least similarly structured pools.
Long tail asset pools typically have low liquidity and lower costs to attack, but not necessarily less risk for an attacker. While low volume decreases the possibility of arbitrage interrupting an attack, there may be highly concentrated liquidity and a low number of tokens circulating in the open market to acquire for the attack. This could make it infeasible for the attacker to find profit.
Anatomy of a Multi-Block Attack
The profitability of a multi-block attack depends on the value of the tokens in the Uniswap pool being less than the value of liquidity in the lending protocol’s target pool. The determination of the value of the Uniswap pool should also take into consideration the cost to manipulate the oracle if the value at the current token price is too high. So the Uniswap pool value may be higher than the value of the lending protocol’s pool, but if the cost to reverse this is less than the lending protocol’s pool value, then the attack can be profitable.
Once the attacker has determined they will be able to profit, they can then figure out if it is more efficient to purchase the required tokens for the attack or to borrow them. First, they would deduct the cost of purchasing the tokens from the profits of selling them on Uniswap in the attack. This would more likely be a loss due to slippage, given that they are trying to lower the price on a Uniswap pool with low liquidity. However, the problem may also be that there are not enough tokens for them to buy, or that they do not have sufficient capital to buy enough tokens. An attacker may also consider that a potential loss would be too high if the cost to buy enough tokens is too high if the attack were to fail.
If purchasing the tokens is too problematic, the attacker could borrow the tokens either from the targeted lending protocol or another one. It is more likely that the attacker would decrease costs by borrowing the tokens from the targeted lending protocol, assuming someone else doesn’t front run the attack. Due to the price changes from manipulating the oracle, it becomes progressively cheaper to borrow tokens from the targeted lending protocol.
Finally, the attacker would consider whether they want to minimize blocks while risking more collateral or attempt multiple rounds of borrowing and selling to utilize less collateral. The ideal situation is to find the minimum amount of collateral required to steal the most amount of deposits. If the price changes or the price cannot drop further to their intended target, then the attack may lock some or all of their collateral in the protocol.
Multi-Block Attack Simulator
We can calculate the potential profit assuming the attacker is borrowing tokens from the targeted lending protocol and selling them to manipulate the price oracle on Uniswap. To do this, we must consider the lending protocol's restrictions such as the borrow and collateral factors if it has both, an amount of collateral to deposit, and the oracle pool liquidity.
Using the Multi-Block Attack , we can enter a deposit amount for collateral, the lending factors, DEX liquidity, lending pool available tokens, and various price inputs for the borrowed and collateral tokens. The spreadsheet will make calculations with the user's input for the number of tokens received from sales on Uniswap along with the new price of the token. The simulator adjusts the new value of the borrowed tokens after each round of sales.
User Position 1 shows the maximum amount of tokens the attacker can borrow based on their deposited collateral. The attacker would sell the max borrowed tokens on the targeted Uniswap pool and input the profit and new price into the Liquidate Round 1 section. User Position 2, and further liquidations rounds, display the new values considering the required collateral for the new borrowed token’s price.
The point of additional rounds is to track how many tokens can be sold to create a desired price impact if the first round is not enough. Users can also determine how much collateral is needed to accomplish a profitable attack in as few sale rounds as possible. Additional sections calculate profit if the attacker leaves their collateral or terminates the attack on a final round, taking whatever profit or loss they’ve accumulated.
Users can simulate different scenarios and construct personalize risk frameworks when working with lending protocols using TWAP oracles. By combining the Euler oracle tool with the Multi-Block Attack Simulator, users can also have a full picture of potential risks for flash loan and multi-block attacks. Additionally, users can run numerous simulations to discover best-practice risk parameters for lending protocols, token categories most at risk of oracle attacks, develop early alert systems, and more.
Users can automate this sheet using APIs, add-ons, or develop an app based on the calculations. The point of a spreadsheet is to ensure a methodology that can be used by anyone in the future, in case an API or app gets removed, restricted, or changes.The focus of this tool is to try to enhance risk awareness and provide greater security for the lending of long tail assets, which are usually not covered by the majority of oracles. This tool also disregards arbitrage and the exact number of blocks in an attack, instead focusing on accounting for potential costs and profits of a multi-block attack.
The contains a user guide, calculations, and an example for users' convenience. Please make a copy and edit the blue cells on the Simulator tab.
Conclusions
While there is great potential to create lending markets for long tail assets, it is evident that the risks to enable safe lending opportunities may outweigh the benefits. Protocols should at least offer more tools so users are aware of the level of risk involved. Long tails assets such as memecoins, governance tokens, and decentralized token launches can benefit from lending markets and derivatives, but these tokens are also the most vulnerable to manipulation.
Unlocking the lending and borrowing potential of long tail assets continues to be tried as efforts include adding more oracles, caps on borrowing, create isolated pools, and delay withdrawals. Volatility controls are uncertain to work on the most illiquid assets because the control likely wouldn't be able to distinguish between genuine price movements and ones intended to manipulate the oracle.
Several lending protocols have looked at creating time based loans. However, the fundamental problem of creating bad debt still exists and lenders would have to be willing to accept that risk. While this study does not delve deeper into this area of lending protocols, variable interest rate-based protocols continue to dominate the market.
Potential solutions could consider looking at the Uniswap volume, liquidity spread, and amount of tokens to determine risk in long tail lending and borrowing markets. Markets given higher risk ratings could be locked or capped until more liquidity is provided to the oracle pool on Uniswap. Some of these factors were utilized in Euler V1’s oracle rating system.
Other solutions are being developed as Uniswap V4 hooks, and on updates and revisions to existing protocols such as Euler V2 and Bunni. Price oracles can also become more efficient when utilizing other types of decentralized exchanges, such as Time-Weighted Automated Market Makers (TWAMM) or the order book-based lending protocol outlined by Bedlam Research. Platforms such as Kamino Finance showcase a number of risk control measures including dynamic LTV, while other protocols including GammaSwap, Timeswap, and Ammalgam offer oracle-less and other solutions.
Ultimately, if there is only one source for prices that is of poor liquidity, almost no amount of risk controls can make it both secure and financially feasible for lending protocol participants.
