How Uniswap V4’s Truncated Oracle Addresses TWAP Vulnerabilities

DeFi lending protocols rely heavily on accurate price oracles for determining collateral values, borrowing limits, and triggering liquidations. Traditional Time-Weighted Average Price (TWAP) oracles, while widely adopted, are inherently susceptible to price manipulation, resulting in potentially devastating unfair liquidations and systemic market inefficiencies. The introduction of Uniswap V4’s Truncated Oracle aims to address these critical vulnerabilities.

The Problem with TWAP: Manipulations

TWAP calculates the average price of an asset over a defined time window by accumulating price snapshots. While intended to smooth out short-term volatility, it fundamentally assumes a relatively stable market environment, which is often not the case in DeFi.

Consider a lending market with a collateralization ratio of 1.9x. A borrower with 10 ETH collateral (ETH price = $2,200) securing a 10,000 USDC loan must maintain at least $19,000 worth of collateral (approximately 9 ETH) to avoid liquidation. 

An attacker can exploit this via a flash loan, executing a large market dump on a low-liquidity exchange, temporarily crashing ETH to $500. This attack is relatively cheap, as the only cost is the flash loan fee. As TWAP includes all price data indiscriminately, it becomes highly vulnerable to this type of manipulation.

Let’s assume TWAP calculates an average based on the last 5 blocks:

Block	ETH Price
Block 1	$2200
Block 2	$2200
Block 3	$2200
Block 4	$2200
Block 5	$500 (Attack)

The TWAP price over these blocks is: 

TWAP = (2200 + 2200 + 2200 + 2200  + 500) / 5 = 1860

Since the lending market uses TWAP, the protocol incorrectly reports ETH at $1,860.

The borrower’s 10 ETH collateral is $18,600 (10 ETH * $1860), which is < $19,000, therefore, the borrower’s position is unfairly liquidated.

Low liquidity pools are especially vulnerable to flash loan attacks, as smaller flash loan amounts can create much bigger price swings.

How Truncated Oracle Prevents Manipulation

A Truncated Oracle is a Uniswap V4 hook that reacts to price changes within a liquidity pool. Unlike traditional TWAP, it employs a modified geometric mean calculation coupled with a crucial per-block price movement cap. This cap effectively limits the impact of sudden, artificially induced price spikes, preventing them from immediately skewing the oracle’s output.

To illustrate, consider a scenario with a hypothetical 5% per-block price cap:

Block	ETH Price	Truncated Oracle Price
Block 1	$2200	$2200
Block 2	$2200	$2200
Block 3	$500 (Attack)	$2090

Instead of dropping to $1860 as in TWAP, the Truncated Oracle only moves to $2090.

For a borrower with 10 ETH collateral, this difference is critical. With the Truncated Oracle’s price of $2090, their collateral value is $20,900 (10 ETH * $2090), which exceeds the required $19,000 threshold, thus preventing liquidation. A TWAP oracle, with the lower price, would have led to an undeserved liquidation.

How Truncated Oracle Can Still Be Manipulated

While Truncated Oracle prevents instant price drops, an attacker can still manipulate the price over multiple blocks by gradually lowering the price by 5% per block.

Block	ETH Price	Truncated Oracle Price
Block 1	$2200	$2200
Block 2	$2200	$2200
Block 3	$500 (Attack)	$2090
Block 4	$500 (Attack)	$1985
Block 5	$500 (Attack)	$1885

The borrower’s 10 ETH collateral is 10 * 1885 = 18850, which is < 19,000, therefore, the borrower’s position is unfairly liquidated. 

This attack took 3 blocks and, while significantly more expensive than a single-block flash loan attack, is still feasible for attackers with substantial capital. Sustained manipulation requires maintaining a large position and repeatedly absorbing arbitrage trades, which can be costly. However, for well-funded attackers, the potential gains from liquidating targeted positions may outweigh the costs.

TWAP vs. Truncated Oracle Price Behavior During Manipulation

Truncated Oracle Implementation in Uniswap v4

The TruncatedOracle library provides the core logic for Uniswap’s Truncated Oracle, which tracks and limits price changes within a predefined maximum per block.

int24 constant MAX_ABS_TICK_MOVE = 9116;

Source: TruncatedOracle.sol 

MAX_ABS_TICK_MOVE = 9116 defines the maximum price movement per block.

Any price change exceeding this value is truncated to prevent extreme swings.

The transform function ensures that price updates never exceed the predefined cap (MAX_ABS_TICK_MOVE):

function transform(Observation memory last, uint32 blockTimestamp, int24 tick, uint128 liquidity)
    private pure returns (Observation memory)
{
    unchecked {
        uint32 delta = blockTimestamp - last.blockTimestamp;

        // Truncate extreme price movements per block
        if ((tick - last.prevTick) > MAX_ABS_TICK_MOVE) {
            tick = last.prevTick + MAX_ABS_TICK_MOVE;
        } else if ((tick - last.prevTick) < -MAX_ABS_TICK_MOVE) {
            tick = last.prevTick - MAX_ABS_TICK_MOVE;
        }

        return Observation({
            blockTimestamp: blockTimestamp,
            prevTick: tick,
            tickCumulative: last.tickCumulative + int48(tick) * int48(uint48(delta)),
            secondsPerLiquidityCumulativeX128: last.secondsPerLiquidityCumulativeX128
                + ((uint144(delta) << 128) / (liquidity > 0 ? liquidity : 1)),
            initialized: true
        });
    }
}

Source: TruncatedOracle.sol 

How This Works

1. The code compares the current tick to the previous tick.
2. If the change exceeds MAX_ABS_TICK_MOVE, it is capped.
3. Updates the cumulative tick and liquidity data.

This mechanism ensures gradual price movement, making it much harder for an attacker to manipulate price oracles in a single transaction.

Thus, truncated oracles partially mitigate the issue of low-liquidity pool manipulation by limiting how quickly the price can shift within the selected time window. Since the oracle only considers a portion of historical price data, sudden price spikes or crashes have a reduced immediate impact, preventing drastic changes in valuation. This makes it more difficult for attackers to exploit low-liquidity pools with flash dumps or pumps, as the price cannot instantly reflect extreme market movements.

The Unresolved Issues of TWAP in Truncated Oracles

While the Truncated Oracle offers significant improvements, it inherits fundamental vulnerabilities from traditional TWAP, particularly concerning time period selection and the handling of insufficient historical data. These issues can still be exploited to manipulate the oracle.

📌 Improper Time Period Selection

TWAP’s vulnerability to flash crashes and delayed pricing remains a concern in truncated oracles:

• Too short a window allows temporary price distortions to influence the oracle.
• Too long a window leads to outdated price feeds that misrepresent real market conditions.

Recommendations:

✅ Do not use an immutable period while considering oracle prices. Instead, set it according to market conditions.

✅ Ensure the time window is carefully chosen to balance responsiveness and stability.

📌Zero-Time Window and Lack of Historical Data

TWAP’s historical dependency issue is also present in truncated oracles:

• If no sufficient price history exists, an attacker can manipulate the oracle by setting arbitrary initial prices.
• Newly deployed pools or single-block updates create opportunities for flash loan price spoofing.

Recommendation:

✅ Require a minimum price update history before the oracle is considered valid.

Conclusion

Uniswap V4’s Truncated Oracle represents a significant advancement in on-chain price oracles, offering enhanced resilience against flash loan manipulation. However, it is not a silver bullet. The fundamental challenges of time period selection, handling insufficient historical data, and the risk of multi-block manipulation remain. Developers must exercise extreme caution and implement robust safeguards to mitigate these risks. Systemic monitoring of the oracle’s behavior, along with adaptive adjustments to the time window and price caps, are essential for maintaining the integrity of dependent protocols.