Liquidity Management
Gamma
DeFiFoundry
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Inflexible Oracle Time Window Triggers Unfair Liquidations on Non‑Arbitrum Chains

iampukar

Summary

The protocol uses a fixed maximum time window maxTimeWindow for validating Chainlink price updates without adjusting for chain‑specific oracle characteristics. While this is tuned for Arbitrum, deployment on other chains—where oracle update delays may be longer—could cause valid prices to be flagged as stale, leading to unnecessary liquidations.

Vulnerability Details

In the KeeperProxy contract’s _check() function, the following validation is performed:

/**
* @notice Checks the price difference between the given price and the Chainlink price.
* @dev Internal function to ensure the price difference is within the threshold.
* @param token The address of the token.
* @param price The price to be checked.
*/
function _check(address token, uint256 price) internal view {
// https://github.com/code-423n4/2021-06-tracer-findings/issues/145
(, int chainLinkPrice, , uint256 updatedAt, ) = AggregatorV2V3Interface(dataFeed[token]).latestRoundData();
require(updatedAt > block.timestamp - maxTimeWindow[token], "stale price feed");
uint256 decimals = 30 - IERC20Meta(token).decimals();
price = price / 10 ** (decimals - 8); // Chainlink price decimals is always 8.
require(
_absDiff(price, chainLinkPrice.toUint256()) * BPS / chainLinkPrice.toUint256() < priceDiffThreshold[token],
"price offset too big"
);
}

This check assumes that oracle updates occur frequently enough that the timestamp is within the specified window. On Arbitrum, this may hold true because the maxTimeWindow is chosen to accommodate typical update delays.

However, on chains with inherently slower updates or during periods of network congestion (such as Ethereum), this fixed window might be too short. In such cases, the function may incorrectly classify a valid (yet delayed) price update as stale, potentially triggering liquidations based on outdated data.

Impact

If valid price data is misclassified as stale, liquidations might be triggered even when market conditions remain normal, penalizing users unfairly. The protocol is tuned for Arbitrum’s update frequency, so no issue is observed. On chains with slower oracle updates, the fixed window may lead to unjust liquidations, making the vulnerability more severe if the protocol is ever cross‑deployed.

Tools Used

Manual Review

Recommendations

Consider implementing a dynamic mechanism that tracks the average update delay of the oracle and adjusts the acceptable window accordingly. An example implementation would look something like this below:-

uint256 maxWindow;
if (block.chainid == 42161) { // Example: Case for Arbitrum
maxWindow = 60; // 1 minute
} else if (block.chainid == 1) { // Example: Case for other chain, such as Ethereum
maxWindow = 3600; // 1 hour
}
require(updatedAt > block.timestamp - maxWindow, "stale price");
Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Admin is trusted / Malicious keepers

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!