Gasless Sponsored Calls, Part 2

Proof of concept: PoC

The current implementation allows both external calls and internal swaps to be executed in the same transaction. Users can externally swap tokens and send them to orderVault as collateral, and later use atomic swaps to receive WNT in order to pay the execution and relay fees.

However, the unrecorded collateral in the orderVault is at risk if the atomic swap uses the same collateral for tokenIn. The following scenario could occur:

• User swaps ARB for USDC in external calls, sends USDC to orderVault.
• User swaps USDC to WNT using atomic swap, sending USDC to orderVault, and later executing

SwapUtils.swap

• Now createOrder is triggered, and collateral is recorded with recordTransferIn
• cache.initialCollateralDeltaAmount will be 0, and user lost the USDC collateral

The issue relies on the fact that orderVault is a StrictBank, so when SwapUtils.swap calls params.bank.transferOut it also triggers _afterTransferOut, syncing the tokenBalances with the current bank balance (which includes the user's collateral).

Prevent users from combining external calls and internal atomic swaps within the same transaction, either through the UI or by implementing on-chain protections.

GMX Team: Acknowledged.

When creating an order using a standalone call, the newly created order's key is returned, which can be utilized for future updates or cancellations. However, when an order is created as part of a batch process, its key is neither validated nor returned during the execution of the batch.

Consider implementing a bytes array as the return value for the batch function. This array should include the newly generated keys for any _createOrder calls within the batch. If the batch contains only updates or cancellations, the function should return an empty array.

GMX Team: Resolved.

The maximum relay fee swap size for sub accounts is capped, and execution reverts if the calculated USD amount exceeds maxRelayFeeSwapUsd.

However, the calculation for this check is currently performed using the min oracle price instead of the max oracle price.

To enhance safety and prevent potentially underestimating the swap size, it would be preferable to use the max oracle price during this calculation.

Consider using the max oracle price for the maxRelayFeeSwapUsd check to provide greater safety and ensure the cap is accurately enforced.

GMX Team: Resolved.

With the newly introduced batch functionality, users can now perform multiple actions in a single operation. GMX also intends to enable users to transfer the required tokens to the orderVault via external calls during the _handleRelayBeforeAction.

// External calls can be used to send tokens to OrderVault. In this case,
initialCollateralDeltaAmount can be zero,
// and there is no need to call _sendTokens.

However, an issue arises when combining the 'batch orders' feature with 'token transfers via external calls' in the following scenario:

Consider a user batching two createOrders actions, each requiring 100 USDC as collateral. The total of 200 USDC will be transferred to the orderVault through external calls, after which the batch function will iterate _createOrder twice.

Since the unaccounted balance of the orderVault is treated as the initialCollateralDeltaAmount (as seen in the code here), the first order will receive the entire 200 USDC as collateral.

The second order, however, will receive 0 USDC, as the entire balance of the orderVault is allocated to the first order during its iteration.

Consider disabling token transfers via external calls for batch orders. Instead, enforce the transfer of tokens directly within the _createOrder function by specifying a non-zero initialCollateralDeltaAmount whenever a batch is used.

This restriction could be implemented at the contract level and also managed in the UI when constructing the batch for the user, ensuring smooth operation and preventing potential issues.

GMX Team: Acknowledged.

Solidity serializes modifiers linearly, meaning the order of execution depends on how they are arranged.

For example, in the function signature: external withRelay(relayParams, account, false) nonReentrant returns (bytes32). The withRelay modifier will be executed first, followed by nonReentrant. Since nonReentrant is checked after _handleRelayBeforeAction and cleared before _handleRelayAfterAction, reentrancy is theoretically possible through both of these functions. However, we couldn't identify a incentive for a normal user to sign off on actions that would enable such behavior.

Theoretically, a sub account might attempt reentrancy via the permit mechanism in _handleTokenPermits. Even so, the only effect would be an increase in gasUsed, resulting in the user paying more gas than necessary—without gaining any real advantage.

Additionally, _handleRelayAfterAction interacts with wnt tokens and hence doesn't allow arbitrary operations. That said, just because we haven't found a concrete exploit path today doesn't mean one won't emerge in the future.

Consider placing the nonReentrant modifier before withRelay for all relevant actions.

GMX Team: Resolved.

The _getCalldataGas function uses hardcoded parameters that cannot be changed after deployment. Specifically:

• calldataLengthLimit is fixed: if (calldataLength > 50000) { ... }
• calldataCostPerByte is also hardcoded: uint256 txCalldataGasUsed = calldataLength * 10;

This lack of configurability limits the protocol's ability to adapt to future changes in gas costs or desired behavior.

Consider making these parameters configurable via the datastore, so they can be adjusted post-deployment if necessary.

GMX Team: Acknowledged.

To verify that there’s minimal delta between what GMX is charged by Gelato and what users refund back to GMX in the case of a sponsoredCall, we fuzzed the following invariant: UPDT-01: WNT increase should match gas spent

• Invariant location
• Setup logic
• Foundry test case

Example observation

Charged:      385,982
Actual:       357,827
Delta:        28,155 (~7%)

We observed a delta in the range of +7–8%. Initially, we attributed part of this to overestimation of calldata bytes (e.g., counting 0-bytes with 10 as a cost), which accounted for 14,562 units in our test case.

Subtracting this gives: 28,155 - 14,562 = 14,593

Later, we realized that:

• The base gas cost includes Gelato contract overhead (e.g., verification and external call)
• Also includes intrinsic Ethereum transaction cost
• However, in our fuzzing setup, we call updateOrder directly and measure gas around the external call, so these should

be excluded

Subtracting both: 14,593 - 21,000 - 10,000 = -16,407

This shows that some overestimations (e.g., calldata cost) and underestimations (e.g., base cost) offset each other, making the final delta difficult to evaluate reliably in a test environment.

• Review the base gas cost configuration and consider increasing it — it is currently set to 40,000, which may not be

sufficient to account for two WNT transfers, as intended. One WNT transfer will always occur.

• Deploy the the gasless routers to a testnet or in a trial phase on mainnet.
• Let a set of on-chain transactions execute under real parameters.
• Analyze the actual delta between what is charged and what is refunded, and adjust the estimation logic accordingly.

Given a list of on-chain transactions, we can assist in perfecting these estimations. On-chain measurements provide more accurate data compared to local test environments (like Foundry or Hardhat), which rely on assumptions that may not reflect production behavior.

GMX Team: Resolved.

The _handleRelayBeforeAction function includes a return statement that attempts to return the result of _handleRelayFee(), but neither of these functions has a defined return value

Remove the return statement.

GMX Team: Resolved.

The GelatoRelayRouter.batch function contains the following comment:

// @note all params except subaccount should be part of the corresponding struct hash

However, the GelatoRelayRouter does not contain any subaccount param.

Modify the comment so it refers to account instead.

GMX Team: Resolved.

When signing transactions with wallets supporting EIP-712 (like MetaMask), users should see a structured, human-readable representation of all critical parameters. However, there are some issues with the current implementation:

• Parameters reduced to bytes32 hashes appear as unreadable hex strings in the signing interface
• Users have no way to verify the content of important parameters like relay fee information or

subaccount permissions

• This creates blind spots where users must trust the frontend application completely

Expand all critical parameters into full EIP-712 typed structures

GMX Team: Acknowledged.

GMX has implemented various protections to minimize the potential damage that malicious subaccounts could cause to their associated primary accounts.

One such potential vector involves subaccounts deliberately increasing gas usage, leading to higher-than-necessary refunds paid by the main account to GMX.

We previously flagged a similar issue in our earlier review, where we discussed the possibility of padding calldata with empty data to artificially inflate gas usage.

A comparable scenario exists with token permits. Since permits are called on arbitrary tokens, a malicious subaccount could pass a poorly optimized or deliberately gas-heavy token, causing the handleTokenPermits logic to consume excessive gas.

While it’s true that the subaccount would be spending its own funds to inflict this kind of griefing on the main account—and would gain no tangible benefit from doing so—we’re raising this again given your decision to address the calldata padding issue in our prior review.

• Either treat this as an accepted trust assumption for subaccounts,

or

• Consider adding guardrails such as:
• Limiting the gas forwarded for permit calls
• Restricting the number of permits processed in handleTokenPermits

GMX Team: Acknowledged.

In the config files, a 6% relay fee premium is applied to the gas cost. However, according to the Gelato docs, a fixed 10% fee premium is charged on both Arbitrum and Avalanche.

Consider setting the premium to 10% if GMX does not have a protocol-specific discount agreement with Gelato.

GMX Team: Acknowledged.