We introduce a novel approach to constructing a Proof of Stake (PoS) resistant oracle system by leveraging Uniswap V4 hooks to mitigate price manipulation through automated backrunning of transactions. The proposed mechanism aims to enhance the reliability and integrity of on-chain price oracles in a PoS environment.
In the context of decentralized finance (DeFi) on Ethereum and other EVM chains, oracles play a crucial role in providing price information for smart contracts. However, with the transition to Proof of Stake, new forms of manipulation, particularly multi-block attacks, pose significant threats to oracle integrity. This work focuses on designing an oracle resistant to such attacks by integrating with Uniswap V4's flexible hook system.
Observation Storage: The oracle stores the last block's observation at the first transaction in a block before any swap occurs, ensuring the most recent non-manipulated state is captured.
Single Oracle per Pair: To reduce complexity and potential manipulation vectors, only one oracle is permitted per trading pair.
Tick Spacing and Range: The maximum allowed tick spacing is used with a full range to minimize manipulation potential by ensuring uniform liquidity distribution.
Enhanced Observation:
Backrunning Mechanism:
Backrun, partially or totally (with a 1bps tolerance for rounding errors), transactions that have a bigger tick delta impact in an afterSwap
hook, charge a fee in the undefined amount to settle hook delta, and mint the purchased token amount back to the user.
Do not backrun transactions below a certain threshold, to allow for inexpensive price adjustment by arbitrageurs.
Geomean Oracle Vulnerabilities:
Geomean oracles are susceptible to multiple-block attacks. These attacks have become possible after the switch of Ethereum to Proof of Stake, as the network can predict who is the block proposer will be for the current and subsequent epoch, therefore opening the door to multi-block MEV attacks, which are more likely due to the high stake concentrated among top validators. Multiple block attacks can executed as a series of multiple 2-block attacks, but a special case to consider is with truncated oracles.
Mitigation Strategy:
2-Block Attack Countermeasures: By focusing on the frequency and impact of 2-block attacks, we aim to make such manipulations either financially risky or ineffective.
Probability Estimation: We estimate the likelihood of attacks by analyzing the current staking distribution, where Lido controls 30% of staked ETH.
Backrunning: We implement backrunning to undo price manipulations within the same or following block, making the attack costly or reducing its effect. By backrunning a swap, we limit the maximum effective tick delta to approximately 2280 ticks, allowing the oracle handle significant price updates while requiring more blocks for larger tick deltas.
3-Block Attack Handling: Although less frequent, 3-block attacks are considered, where an empty block could be used between manipulation steps. By tracking the tick delta, we introduce financial risk or uncertainty for the attacker, who will then be required to execute a series of consecutive backrun transactions. This means that the attacker will need to control more blocks (many more blocks) to remove such uncertainty.
Generalized Approach: The mechanism works against both frontruns and backruns, maintaining resilience regardless of the initial block state. A minimum price impact to 912 ticks minimizes the extra gas costs for standard transactions. Extended attacks face continuous backrunning by the hook, creating financial uncertainty for the attacker.
Tick Limit: We set a maximum (9118) and a minimum (912) number of ticks that slot0 can cross in one block, with the minimum triggering a partial backrun, scaling up to full backrun at the maximum (minus 1bps tolerance for rounding errors).
Backrun Strategy:
For swaps below the minimum tick movement, no backrun is executed.
Above the minimum, the backrun amount increases linearly from approximately 10% to 99.99% of the swap amount, making large manipulations gas-expensive and risky.
No Fee for Liquidity Providers: The focus is on system integrity rather than rewarding liquidity provision.
No Lockup for Liquidity Providers: Liquidity can be removed without incentive for manipulation since no fee is paid.
Exact Input Swaps Only: By restricting user swaps to exactInput
types, we can charge a fee in the undefinedAmount
to settle the hook delta in the afterSwap
hook call (the hook delta is returned as hook fee).
Refund to user: The hook’s positive delta is returned to the user as a credit in the Pool Manager contract.
Effectiveness: While not eliminating manipulation risks, this approach significantly reduces impact, especially for less liquid tokens.
Comparison: Offers real-time updates, resistance to off-chain manipulation, and universality without aggregation.
Economic Considerations: Introduces barriers to manipulation, potentially requiring attackers to control more blocks or accept financial risk or losses.
The proposed oracle system using Uniswap V4 hooks offers a robust method for minimizing price manipulation in PoS environments. Addressing immediate and subsequent block manipulations through strategic backrunning and liquidity management could set a new standard for oracle security in DeFi.
Financial Cost: Introducing additional fees could enhance manipulation resistance but might discourage arbitrageurs under volatile conditions
Autocompounding liquidity: The hook could swap only half of the calculated amount, and use both tokens to provide liquidity, becoming progressively more resistant to attacks.
Liquidity Handling: Locking liquidity could ensure price availability but reduce pool liquidity; a compromise could involve temporary lockups.
Small Scale Manipulations: These remain possible but are financially less viable than traditional pump-and-dump strategies.