Keeper dependency could lead to missed opportunities, financial losses, and user dissatisfaction
Summary
The contract relies on keepers to execute critical functions. If keepers fail to perform their duties (e.g., due to insufficient gas or downtime), the protocol could become non-functional.
Vulnerability Details
This vulnerability can be found in the lines of code below;
Proof of Concept (PoC):
-
A keeper runs out of gas during a critical market movement, causing delayed position closures and significant losses for users.
-
Example:
function run(address perpVault, bool isOpen, bool isLong, MarketPrices memory prices, bytes[] memory _swapData) external onlyKeeper {
_validatePrice(perpVault, prices);
IPerpetualVault(perpVault).run(isOpen, isLong, prices, _swapData);
}If the keeper fails to execute
run, the protocol may miss critical actions.
Impact
Keeper failure could lead to missed opportunities, financial losses, and user dissatisfaction.
Tools Used
deepseek
Recommendations
Implement a decentralized network of keepers to reduce reliance on a single entity.
Introduce a fallback mechanism for users to manually trigger actions if keepers fail.
Use a reputation system to incentivize honest and efficient keeper behavior.
Lead Judging Commences
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."
Suppositions
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.