Skip to content

Latest commit

 

History

History
48 lines (30 loc) · 2.89 KB

064.md

File metadata and controls

48 lines (30 loc) · 2.89 KB
Raw

Harsh Sable Sparrow

medium

Fixed addresses will cause issues if contract is deployed on chains other than Optimism

Summary

The OptimismRewardCollector contract uses fixed addresses for interacting with external contracts and tokens, which are specific to the Optimism network. However, these addresses are not compatible with other chains. Also, the stale period 1200 seconds used for the oracle price validation is too short for Ethereum and Arbitrum

Vulnerability Detail

According to the README:

Reward router/collector The reward router/collector is only currently intended to be deployed on Optimism, Arbitrum, and Ethereum.

Using fixed addresses across networks without validation or adaptation can lead to incorrect interactions with unintended contracts, potentially leading to loss of funds or failed transactions.

The ETH / USD oracles on different chains are:

On Ethereum, the oracle will update the price data every ~1 hour. On Optimism, the oracle will update the price data every ~20 minutes. On Arbitrum, the oracle will update the price data every ~24 hours.

On Arbitrum and Ethereum, 1200 seconds is too small. Specifically, if the protocol is deployed to Arbitrum or Ethereum, the protocol will be unable to operate because the if (updateTimeEth < block.timestamp - 1200 seconds) condition will be met, causing a transaction to be reverted in the getExpectedExchange().

Impact

Deploying this contract as is on networks other than Optimism can result in calls to non-existent contracts or addresses which will permanently revert the tx or at worse cause loss of tokens. Plus, setting the stale period too small could render the contract unable to operate.

Code Snippet

https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L30-L34 https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L68-L69 https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L75-L76 https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L65 https://github.com/sherlock-audit/2024-04-alchemix/blob/main/v2-foundry/src/utils/collectors/OptimismRewardCollector.sol#L72

Tool used

Manual Review

Recommendation

  • To ensure compatibility and safety across different networks, the contract should implement dynamic address configuration.

  • Even on the same chain, different tokens can have different heartbeats. Consider using the mapping data type to record a TIMEOUT value of each token and setting each token's TIMEOUT with an appropriate stale period for each chain.