QuantAMM

Summary

The performUpdate() function in the UpdateWeightRunner contract allows any external address to trigger weight updates for pools. While updates themselves are deterministic and have timing constraints, the permissionless nature of who can trigger them creates opportunities for malicious timing manipulation:

https://github.com/Cyfrin/2024-12-quantamm/blob/a775db4273eb36e7b4536c5b60207c9f17541b92/pkg/pool-quantamm/contracts/UpdateWeightRunner.sol#L279

The vulnerability arises from the permissionless update mechanism creating strategic timing opportunities. The attack vector exists due to the predictable and deterministic nature of the weight updates combined with unrestricted access to trigger them. When monitoring the mempool for pending trades, an attacker can precisely calculate the optimal timing of weight updates to maximize value extraction.

For example, an attacker who spots a large pending trade can simulate the outcome of triggering a weight update pre-trade versus post-trade. By front-running with a strategically timed update transaction at a higher gas price, they can force the trade to execute under whichever price conditions are most profitable for the attacker. The deterministic weight calculation combined with controllable timing creates a pure arbitrage opportunity.

This fundamentally undermines the Chainlink automation infrastructure intended to handle updates. Even though Chainlink provides the base automation layer, any actor can easily circumvent it by racing with higher gas prices to seize control of update timing. This transforms what should be a predictable automated process into a competitive MEV extraction opportunity.

The economic implications cascade through the entire protocol's operations. Beyond the direct value extraction from sandwiched trades, the system suffers from increased gas costs as bots engage in update timing wars. The unpredictable timing erodes price stability since updates occur based on MEV opportunity rather than consistent intervals.

Recommended Mitigation Steps

1. Implement a keeper registry system:

1. Restrict update access to authorized keepers: