Gasless Transactions

The introduction of fee swaps to pay the executor allows for users to do arbitrarily large swaps in a single transaction without first initiating this action on chain.

Before the introduction of gasless transactions this ability was not allowed on the GMX Exchange and it was explicitly disallowed for atomic withdrawals to include swaps.

Gasless transactions unintentionally introduces a way for users to achieve single transaction swaps by using a higher than needed fee swap input amount and receiving the excess amount back.

Furthermore, the swap made in this instance uses the normal swap fees as computed by the SwapUtils.swap function. There is no application of the AtomicSwap fee pricing.

Consider removing the fee swap feature so that the ability for users to perform swaps in a single transaction is not unintentionally introduced with this update.

Otherwise, keep the feature and limit the size of swap that is allowed to be carried out from this, and furthermore charge the higher AtomicSwap fee rate for these swaps.

GMX Team: Resolved.

In the _updateOrder function there is no logic to support sending wnt tokens to the order vault to cover any fee increase related to the update of an order.

This means that any order updates which result in a higher executionFee being required will not be possible through gasless transactions.

Include logic to transfer additional executionFee wnt value to the OrderVault to be able to successfully update orders which would have an increased executionFee.

GMX Team: Resolved.

In the _getCreateOrderStructHash the decreasePositionSwapType value is not included in the resulting hash and therefore cannot be validated.

The caller of the createOrder function can then decide the value of the _getCreateOrderStructHash on the params.

This can be used to cause loss or unexpected outcomes for the user as their position and integrating addresses may not have support for a particular receiving token.

Include the params.decreasePositionSwapType in the _getCreateOrderStructHash function.

GMX Team: Resolved.

The SubaccountRouter contract lacks validation for the cancellation receiver in the createOrder function.

This way sub accounts can potentially create orders with a large initialCollateralDeltaAmount on them and cancel them with the cancellationReceiver as their own address to drain the main account's assets.

Consider adding the cancellationReceiver validation to the createOrder function in the SubaccountRouter contract.

GMX Team: Resolved.

In the createOrder function the receiver and cancellationReceiver addresses are validated against the account to ensure that funds are not sent to an address that is not controlled by the position owner.

However there is no validation on the callback contract which will take a higher priority than the cancellationReceiver or receiver when the executionFee is refunded.

If it is important for the protocol to ensure that sub accounts cannot siphon the refund fee this way, consider validating that the provided callback contract is the saved callback contract for the account and market.

Otherwise be aware of this issue and clearly document it for users and integrators of the sub account feature.

GMX Team: Resolved.

The removeSubaccount function is not outfitted to be a gasless transaction function. The function is missing the _handleRelay logic and does not have a onlyGelatoRelay modifier.

Outfit the removeSubaccount function so that it can be used by the Gelato relayer in a gasless manner.

GMX Team: Resolved.

In the _handleTokenPermits function if the existing allowance for the spender is greater than the required amount then the permit signature is not used.

However this allows for a malicious DoS in the future because the permit signature is now public and the corresponding nonce has not been used.

The next time the same signer wishes to use the corresponding nonce for a permit to the same token a malicious actor can submit the permit they signed in the past to use the corresponding nonce before the user's newly signed permit is executed.

This can be carried out for future interactions with the GMX system or any other permit application for the token.

Consider always using the permit signature no matter if it is unnecessary and instead determine if the permit is necessary at the UI level.

GMX Team: Resolved.

When determining how much to top up it the contract calculates the amount of gas used as follows:

uint256 nativeTokensUsed = (startingGas - gasleft()) * tx.gasprice + executionFee

The issue with this is that there is ample logic and gas consumed after this calculation. None of which will be considered for refund. Meaning that a sub account will always get an insufficient refund in terms of the additional top up logic.

Add a topUpgas variable to the calculation which contains the amount of gas that will be consumed after the calculation.

GMX Team: Acknowledged.

Before any action is executed that a user can take GMX will call updateFundingAndBorrowingState to update the borrowing rate of traders in the underlying pool.

However currently a swap through the gelato routers will occur without making any update which means that subsequent borrowing fee rate calculations are incorrect between the period of the swap and the next position update. Causing an incorrect amount of borrowing fees to be charged.

Consider updating the borrowing and funding state with updateFundingAndBorrowingState before a swap occurs in a market.

GMX Team: Acknowledged.

An account can have many sub accounts all of which will have access to the same funds. Because of this users may end up having more funds traded then expected.

Consider giving the user control over how much a sub account can spend, or document to users that all sub accounts share the same total allowance

GMX Team: Acknowledged.

The execution fee and gelato fee come from the same source, fee.feeAmount. That means if a user wants to use USDC to pay gelato when creating an order they will have to pay a (swap) fee to pay a (gelato) fee.

It also means that executionFee for GMX will not be sufficient at times since for createOrder it is just sending over the residual amount, so even in cases where there is no swap there is still the case where Gelato fee increases and reduces the residual amount that can be used for GMX executionFee.

Consider separating the execution fee and the gelato fee so that users can provide wnt for the execution fee without paying a fee on it.

GMX Team: Acknowledged.

In the Errors.sol file the SignatureType enum is not used throughout the codebase.

Remove the unused SignatureType or implement it's intended use-case.

GMX Team: Resolved.

There is currently no feature to deactivate gasless transactions in the event that they need to be.

Consider adding a gasless transactions wide feature that can be disabled, and when disabled no gasless transactions can be executed.

GMX Team: Resolved.

In the _handleTokenPermits function a permit is made to an arbitrary token. However since the permit signature must exist in the transaction calldata it is visible in the mempool for chains like Avalanche which have a public mempool.

This allows malicious actors to frontrun the relayer and submit this permit in a separate transaction, causing the relayer's execution of the action to fail.

Either ensure that the relayer is using a private RPC or consider adding logic to continue if the permit action fails, since in the case where a malicious actor has frontrun the permit the approved value has already been given.

GMX Team: Resolved.

The SubaccountGelatoRelayRouter allows users to create, update and cancel orders using a subaccount and relaying transaction with Gelato. All subaccount GMX interactions are done directly using the SubaccountUtils, skipping the SubaccountRouter.

During _handleSubaccountAction, it will validate if the subaccount feature is enabled for the SubaccountGelatoRelayRouter.

Therefore, if the sub account feature is disabled for SubaccountRouter, it will still be available using. SubaccountGelatoRelayRouter. This can create unexpected scenarios, if both features are not disabled at the same time.

Document this scenario and make sure that both subaccount features are disabled at the same time.

GMX Team: Acknowledged.

The _swapFeeTokens function does not perform any validation on the length of the swap path provided. This does not adhere to the maximum swap length allowed on the GMX exchange for canonical orders.

Consider validating the swap path in the _swapFeeTokens function to avoid any unexpected behaviors.

GMX Team: Resolved.

The router contracts will pay the Gelato relayer a fee during _transferRelayFee. To ensure there is a heightened control over the fees, Gelato suggests to use _transferRelayFeeCapped with a maxFee that will prevent transactions to be executed if the relayer fee is above a certain limit.

Introduce a maxFee parameter, either in the function call, or as a state variable, and use _transferRelayFeeCapped instead.

GMX Team: Resolved.

The payable modifier is added to the removeSubaccount function, however this function does not do anything with the accepted Ether value.

Remove the payable modifier from the removeSubaccount function.

GMX Team: Resolved.

In the swap for the fees for _swapFeeTokens the orderKey provided is the same as the order key that will be created.

The order that is created could also be a swap order and thus there may be confusion about which events correspond to the order execution and which correspond to the fee swap for the order.

Confirm whether or not this is expected behavior. If it is not or the behavior should be made more clear, consider assigning a different order key which is unique to, but different from, the order being swapped for in the fee swapped.

GMX Team: Resolved.

In the Relay Signature verification logic for _validateCall and _handleSubaccountApproval a monotonically increasing nonce is used to validate actions by a signer.

However since the message nonce execution must be in order if multiple messages were to be signed and one message were to fail execution then it would prevent all subsequent messages from being executed.

The message could fail execution for a number of reasons including but not limited to a deadline invalidation, a swap failure, or an errantly missing approval.

Consider using unique nonces which are not required to be monotonically increasing so that if one message fails it does not prevent messages signed with a higher nonce from being executed.

GMX Team: Acknowledged.

The contract validates if the requiredRelayFee sent by Gelato Router is greater than the output amount returned from swapFeeTokens.

However, the function will still revert without that validation, during _transferRelayFee during the token transfer if the relay params did not specify the correct amount.

Similarly, if the remaining fee tokens (residual) are not enough to cover the executionFee, the transaction will revert in the orderHandler call.

Avoid redundant token balance checks as they are already handled during transfer functions.

GMX Team: Acknowledged.

In the _swapFeeTokens function there is no validateMarketTokenBalance validation after the swap. However this validation is performed throughout the codebase whenever a swap occurs to validate that no market balances were perturbed by a swap.

Add validateMarketTokenBalance validation after the swap is invoked in the _swapFeeTokens function.

GMX Team: Acknowledged.

The _handleTokenPermits function does not validate that each target token supports the permit functionality.

This lack of validation can lead to unexpected behaviors if the permit function is routed to a token contract's fallback function instead of the expected permit function, which does not exist on that token. No particularly malicious behaviors on popular tokens has been identified at this time.

However with many tokens being supported on the GMX system and more to be added in the future, out of an abundance of caution it may be appropriate to validate that the tokens used with the _handleTokenPermits function are a whitelisted for permit use within GMX.

Consider adding validation to ensure that tokens used in the _handleTokenPermits function do indeed support permit functionality and are allowed by a whitelisted list.

GMX Team: Acknowledged.

The _handleRelayFee will handle Gelato relay fee payment, as well as GMX executionFee. However, when the fee token is wnt, it will perform unnecessary transfers from/to the orderVault:

• transfer tokens from user to OrderVault (_handleRelayFee)
• transfer out feeAmount from OrderVault (_swapFeeTokens)
• transfer relay fee to collector (_transferRelayFee)

Do not transfer fee tokens from user to orderVault if the fee.feeToken = wnt and instead send them to the router contract. Then, avoid the call to _swapFeeTokens and only call _transferRelayFee as the tokens are already in the router.

GMX Team: Resolved.

An account can steal funds from the subaccount by manipulating the top up amount. The way this would be done is an account would signal to the sub account to create an order.

Then the account will frontrun the sub account and decrease the top up amount, this will truncate the amount the sub account should be refunded to only a dust amount.

Next the account will cancel the order where the execution fee will be sent to the cancelation receiver (account). If the subaccount is a bot or has any automation this attack would be easy to repeat stealing funds each time.

Consider putting a small time lock on setSubaccountAutoTopUpAmount and setMaxAllowedSubaccountActionCount

GMX Team: Acknowledged.

When an account does not have enough funds or allowance to repay the subaccount in the _autoTopUpSubaccount function it will return early. An account can leverage this by frontrunning a sub account and revoking allowance or transferring funds.

Leading to the sub account not being compensated for paying the execution fee. An account can do this repeatedly to avoid all execution fee costs.

Instead of returning early either revert, or include an additional parameter where the sub account can choose if they want to waive the refund.

GMX Team: Acknowledged.

The user can generate a sub account, the sub account action is managed by sub account router. However, in the newly added code, the sub account, if compromised, can directly make the main account lose money by executing a swap.

The swap logic let the main account transfer the fee.feeToken and swap the fee token to output WETH token to pay for the relayer fee. The swap has minimum slippage control (minOutputAmount is _getFee()), so the main account can suffer from slippage loss when executing the swap.

The sub account can also compose a long swap path market pass to force the main account pay high gelato relayer fee.

Document such attack vector if the sub account is compromised. Validate the fee.feeSwapPath and the amount of fee token (input token) the sub account can be used to swap for the WETH relayer fee.

GMX Team: Acknowledged.