In the afterOrderExecution function, we emit the GmxPositionUpdated event when the flow is SIGNAL_CHANGE. This event includes the isOpen parameter, which indicates whether the signal change resulted in a position open(true) or a position close(false).
However, this event is not emitted when a signal change opens or closes a 1x long position for the vault (Note that this event is reached during a signal swap i.e. - changing from 1x long to short since the flow is not deleted in _updateState as nextAction is set to INCREASE_ACTION during that flow). This occurs because the _updateState function deletes flow for 1x positions, causing the condition if (flow == FLOW.SIGNAL_CHANGE) in afterOrderExecution to evaluate as false. As a result, no event is emitted during a signal change for 1x long positions.
Additionally, even if the event were emitted, it would provide incorrect isOpen information for these 1x positions. This is due to the logic used to determine isOpen, which relies on orderResultData.orderType == Order.OrderType.MarketIncrease. Since opening and closing a 1x long position always results in orderType = MarketSwap, this approach fails to accurately represent whether the signal change led to a market increase or decrease.
Incomplete Event Logs – The absence of GmxPositionUpdated for 1x long positions means that external systems monitoring position updates will not receive signals for these changes, leading to data inconsistencies.
Incorrect Position Tracking – Since the isOpen flag is determined using orderResultData.orderType == Order.OrderType.MarketIncrease, the event (if emitted) would incorrectly classify 1x long position changes. This could mislead analytics, risk management, or automation processes that depend on accurate event data.
Potential Misalignment with Vault Strategy – If vault strategies or automated decision-making processes of keeper rely on event-based triggers, missing or incorrect event emissions could lead to unintended behavior, such as improper rebalancing or failure to adjust leverage correctly. (Hence why the medium evaluation)
Manual Review
Foundry
For 1x LONG signal changes change the event emission logic to make sure the event GmxPositionUpdated is logged for 1x long open/close signal changes
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.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.