Liquidity Management

Summary

The getExecutionGasLimit function in the GMXProxy contract contains a hardcoded value for oraclePriceCount, which is set to 5. This limits the scalability of the contract, as the system will fail to correctly estimate gas limits when more than 5 oracle prices are involved.

Affected Line of Code:

https://github.com/CodeHawks-Contests/2025-02-gamma/blob/main/contracts/GmxProxy.sol#L149-L197

Finding Description

The oraclePriceCount is currently hardcoded to 5 in the getExecutionGasLimit function, which directly influences the gas limit estimation for transactions that depend on oracle prices. This poses a problem because, if the number of oracle prices increases beyond 5, the gas calculation will be incorrect.

This security issue violates the scalability and correctness guarantees of the system. A dynamically adjustable method for determining the oraclePriceCount is necessary to accommodate different oracles, preventing transaction failures when gas limits are inaccurately calculated.

Security guarantees broken:

• Scalability: The system is unable to adjust to changes in the number of oracle prices, making it prone to failure when oracle counts exceed 5.

• Correctness: Hardcoding the number of oracle prices means the system will not correctly calculate gas limits for scenarios requiring more than 5 oracles.

Impact Explanation

By having a fixed oraclePriceCount, the system will fail to adjust to different oracle configurations, leading to incorrect gas estimations and potentially causing transactions to revert or fail. This problem is particularly problematic as the number of oracle prices may change over time, either due to protocol upgrades or changes in market conditions.

This could impact users’ ability to submit orders, execute swaps, or perform other interactions with the contract. If left unresolved, this issue could affect the protocol's functionality and user experience, resulting in a loss of confidence or trust.

Likelihood Explanation

The likelihood of this vulnerability causing problems increases as the number of oracle prices grows. Although there may currently be fewer than 5 oracle prices, this hardcoding becomes a significant issue as the system scales. Since it's a fixed number, any increase beyond 5 will directly lead to errors in gas estimation and transaction failures.

Given that protocols generally evolve to support more oracles over time, this issue is highly likely to be encountered as the project progresses and its usage expands.

Proof of Concept

A Proof of Concept (POC) is not required for this submission, as the vulnerability is evident from the code analysis and does not require a malicious input to be demonstrated. The vulnerability stems directly from the hardcoded value, and increasing the number of oracle prices in the system will expose this issue.

Recommendation

To resolve this issue, replace the hardcoded value of oraclePriceCount with a dynamic calculation or method that fetches the actual number of oracle prices involved. Here's an example of how this can be fixed:

This modification ensures that the contract can handle any number of oracle prices, thus maintaining scalability and ensuring accurate gas limit calculations for various scenarios.

Severity

• Impact: Medium
  This issue can cause transaction failures and disrupt the functionality of the protocol as the system scales, but it does not result in direct loss of funds or a critical security breach.

• Likelihood: High
  As more oracles are introduced into the system, this issue is highly likely to occur, making it a pressing concern for the future scalability of the contract.