GmxProxy contract allows order creation and settlement without sufficient execution fees, potentially leading to failed transactions on GMX. This breaks the requirement that all GMX interactions must have adequate execution fees to compensate keepers. Occurs when the GmxProxy contract processes orders with insufficient ETH balance for execution fees. The contract's minEth check exists but can be bypassed, similar to trying to send a package without paying sufficient postage, it gets accepted initially but fails at delivery.
The core functionality revolves around a vault system where users deposit USDC as collateral. This collateral is then used to manage leveraged positions on GMX perpetual markets, with each vault dedicated to a specific market and leverage ratio (ranging from 1x to 3x). For example, separate vaults exist for 1x ETH, 2x ETH, and 3x ETH positions.
When a user initiates a position through PerpetualVault, the request flows to GmxProxy which should ensure sufficient ETH exists for GMX keeper execution fees. The contract checks if its balance exceeds minEth (0.002 ETH), but here's where things get interesting:
The execution fee validation in createOrder() looks promising at first glance: GmxProxy#createOrder
However, the contract allows orders to proceed even when msg.value is lower than minEth. This creates a scenario where orders enter the GMX system but lack the necessary fees for keeper execution.
When an order lacks sufficient execution fees:
The GMX keeper network won't process it
The position remains in limbo
Users lose their partial execution fee payment
The vault's position management capabilities become blocked
It disrupts the core automated position management that makes the Perpetual Vault system valuable to users seeking hands-off leveraged trading.
The protocol's key innovation is its automated position management through a Keeper system. When users deposit funds, they're essentially delegating trading execution to the protocol's automated strategies. For 1x long positions, the system can execute trades through either GMX spot markets or Paraswap for optimal pricing. For leveraged positions (>1x) or shorts, the system interacts directly with GMX's perpetual markets.
Imagine a busy highway where cars can enter without paying the toll, only to be permanently stuck at a checkpoint. The GmxProxy contract creates this exact scenario by allowing position orders to enter GMX's system without proper execution fees, leading to permanently stranded positions.
When users interact with the Perpetual Vault to manage leveraged positions, their requests flow through GmxProxy which acts as the gatekeeper to GMX's perpetual trading system. The contract attempts to ensure sufficient ETH exists for keeper execution fees, but its validation has a critical oversight.
When an order enters without proper execution fees (less than 0.002 ETH), it becomes permanently stuck in GMX's queue. The keepers, who require proper compensation to execute orders, will perpetually skip these underfunded positions. This breaks the vault's core promise of automated position management.
Consider this validation to ensure proper execution fee handling while maintaining compatibility with the broader system architecture including PerpetualVault's automated position management and GMX integration.
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.
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.