QuantAMM

Summary

A vulnerability has been identified in the MultiHopOracle contract's _getData() function where the implementation lacks proper timestamp validation mechanisms. The contract's core logic is centered around a simplistic timestamp tracking approach that only records the oldest timestamp among all oracle readings:

https://github.com/Cyfrin/2024-12-quantamm/blob/main/pkg/pool-quantamm/contracts/MultiHopOracle.sol#L40

The fundamental flaw in this design stems from the absence of temporal consistency checks between oracle data points. When aggregating prices across multiple oracles, the contract fails to ensure chronological coherence of the pricing data. This architectural weakness manifests in several dimensions:

The contract operates without temporal bounds verification, allowing the combination of price feeds from disparate time periods. Moreover, there's no synchronization enforcement between sequential oracle readings, which can result in price derivations from inconsistent market states. This issue is exacerbated by the lack of staleness validation against the current block timestamp.

The severity of this vulnerability is particularly pronounced within QuantAMM's TFMM (Temporal Function Market Making) framework, where oracle price accuracy directly influences pool weight dynamics. The attack surface extends beyond simple price reporting, as it can cascade into pool weight calculations, strategy execution parameters, and ultimately affect LP positions.

Malicious actors can exploit this vulnerability by selectively targeting price disparities during high volatility periods. By constructing transactions that leverage the timestamp inconsistency, attackers can manipulate the effective exchange rates used for trades. The impact is magnified in multi-hop oracle paths where price differences can be compounded across multiple token conversions.

Furthermore, the vulnerability creates systemic risk within the QuantAMM ecosystem as the compromised price feeds affect:

• Dynamic pool weight adjustments, potentially leading to suboptimal portfolio allocations

• Strategy execution timing and effectiveness

• LP position valuations and withdrawal calculations

• Arbitrage boundaries and market efficiency mechanisms

Proof of Concept

Consider this scenario:

1. Bob is monitoring market conditions where:

   • ETH trades at $2000

   • BTC trades at $50,000

   • ETH/BTC ratio is 0.04

2. A market flash crash occurs:

   • ETH price rapidly drops to $1800

   • BTC price drops to $48,000

   • Actual ETH/BTC ratio should be ~0.0375

3. The MultiHopOracle's price feed consists of:

   • Oracle A: Fresh ETH/BTC data from 1 minute ago

   • Oracle B: Stale BTC/USD data from 30 minutes ago

4. Alice, a sophisticated trader:

   • Notices the stale data in the oracle path

   • Sees that the oracle is returning inflated prices

   • Executes trades using this price disparity

   • Profits from the difference between actual market price and stale oracle price

5. The pool processes Alice's trade at the incorrect price due to mixed timestamps

6. LPs suffer losses as trades execute at non-market prices

7. This exploitation can continue until the stale oracle updates

In this scenario:

1. An attacker could wait for significant price movements

2. Use the stale price combination for profitable trades

3. The reported timestamp would only indicate the oldest data point

Recommended mitigation steps

1. Add maximum age validation:

1. Add configuration options for time parameters:

• Allow admin to adjust MAX_ORACLE_DELAY based on market conditions

• Enable fine-tuning of MAX_TIME_DEVIATION for different oracle combinations

• Implement emergency pause if oracle data becomes too stale

1. Add event emissions for monitoring:

These mitigations would significantly reduce the risk of price manipulation through timestamp inconsistencies while maintaining system flexibility.