Keeper transactions are vulnerable to MEV bots front/back-running due to lack of order uniqueness protections.
The PerpetualVault contract allows keepers to execute orders without unique identifiers, making it possible for attackers to detect pending transactions in the mempool and front-run them with identical orders. This results in the attacker's order being executed first, causing the legitimate order to execute at a worse price, leading to potential economic losses for the protocol and its users.
Root Cause:
The root cause of this issue is the lack of order uniqueness protections and slippage control in the PerpetualVault contract. The contract does not use unique identifiers for transactions, allowing attackers to duplicate and front-run orders.
Proof of Concept:
Copy and paste in PerpetualVault.t.sol and run
Economic Losses: The protocol and its users may suffer economic losses due to front-running attacks.
Price Impact Exploitation: Front-run orders amplify price movement for back-run profit.
Lack of Slippage Control: No per-order max slippage checks allow unlimited price impact.
Manual
Commit-Reveal Scheme:
Implement a commit-reveal scheme to ensure order uniqueness and prevent front-running.
MEV-Resistant Order Types:
Implement MEV-resistant order types with unique identifiers and slippage control.
Slippage and deadline are handled externally. Paraswap implementation used by the current code (behind the proxy): https://etherscan.io/address/0xdffd706ee98953d3d25a3b8440e34e3a2c9beb2c GMX code: https://github.com/gmx-io/gmx-synthetics/blob/caf3dd8b51ad9ad27b0a399f668e3016fd2c14df/contracts/order/OrderUtils.sol#L150C15-L150C33
acceptablePrice does that job for increase/decrease positions. https://github.com/gmx-io/gmx-synthetics/blob/caf3dd8b51ad9ad27b0a399f668e3016fd2c14df/contracts/order/BaseOrderUtils.sol#L276C49-L276C66
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.