boredpukar - Misalignment in Expected and Actual Oracle Update Frequency Leading to Frequent Reverts

[github-actions]

boredpukar

high

Misalignment in Expected and Actual Oracle Update Frequency Leading to Frequent Reverts

Summary

The misalignment between the expected update frequency hardcoded into the smart contract and the actual update frequency provided by Chainlink oracles can lead to several critical issues, such as frequent transactions revert.

Vulnerability Detail

The getExpectedExchange function calculates expected exchange rates based on the latest round data from Chainlink oracles. It incorrectly assumes that the update frequency is uniform across different networks (like Arbitrum and Optimism). This assumption can lead to logical errors in environments where the actual update frequency is significantly longer, as seen on the Arbitrum network.

In the Optimism network, the heartbeat of OP/USD and ETH/USD pair is set to 1200 seconds. Reference.

However, in Arbitrum network, the heartbeat of OP/USD and ETH/USD pair is set to 86400 seconds. Reference.

Impact

Imagine a scenario where a user attempts to use the getExpectedExchange function on the Arbitrum network:

• The Chainlink oracle updates the OP/USD and ETH/USD every 86400 seconds.
• The user calls the function shortly after an update, and then again 1300 seconds later.
• The second call will fail because the update time check (1200 seconds) is exceeded, even though the oracle data is still relatively fresh by the oracle's standards.

Code Snippet

https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L110
https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L128

      if( updateTime < block.timestamp - 1200 seconds ) {
            revert("Chainlink Malfunction");
        }

     if( updateTimeEth < block.timestamp - 1200 seconds ) {
            revert("Chainlink Malfunction");
        }

Tool used

Manual Review

Recommendation

The smart contract needs more flexible and network-aware handling of oracle data freshness. For this, it can implement network-specific parameters for oracle freshness checks. These could be set during the deployment or through a configuration function that can adjust the freshness threshold based on the network.

Duplicate of #14