User's order executionFee is stored in the depositInfo[depositId].executionFee
, According to the protocol, users must pay an execution fee when a deposit or withdrawal triggers a GMX order execution; otherwise, the fee is refunded. The allocation of the execution fee is handled in the PerpetualVault::_payExecutionFee
function, where, if msg.value
exceeds minExecutionFee
, the amount is transferred to the gmxProxy
contract and stored as the execution fee. However, the execution fee calculation within _payExecutionFee
is incorrect.
current state, positionIsClose == false, beenLong == false, leverage == 10_000
User deposits 1e10
collateral token with msg.value
as 2e18
.
The depositInfo[depositId].executionFee
of user is stored as 1e18
.
Increase position order is placed on GMX
.
User is minted corresponding shares based on the depsoited value without getting any refund on the deposit.
now, if the state changes to beenLong == true.
User calls the withdraw function with msg.value
as 1e10
.
User pays the executionFee which will be overridden to 1e18
.
And when the user receives the remaning of the executionFee, the amount received by the user will be less than what they deposited.
Add this test to PerpetualVault.t.sol
and run forge test --mt test_executionFeeReturn --via-ir --rpc-url arbitrum -vvv
This could lead to wrong allocation of executionFee leading to user loosing funds while claiming the the executionFee as a refund.
According the sponsor, here is the design choice: - when there's gmx interaction, no refund. - when there's no gmx interaction, refund fee. The remaining fees are used for gas cost of the keepers.
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.