Skip to main content

Advanced entry points

This page covers the contract surfaces beyond the core ExchangeRouter / GlvRouter flow: delegated subaccount trading, gasless relay routers, and multichain GMX Account routers. Some of these are end-user or integrator entry points, while others are specialized router or controller surfaces.

For the core request lifecycle, see Architecture. For standard GM and GLV actions, see ExchangeRouter and GlvRouter.

SubaccountRouter

SubaccountRouter lets a main account delegate order management to a subaccount without giving that subaccount full custody of the account.

Management functions

FunctionPurpose
addSubaccount(address subaccount)Authorize a delegated subaccount
removeSubaccount(address subaccount)Remove a delegated subaccount
setSubaccountExpiresAt(address subaccount, bytes32 actionType, uint256 expiresAt)Set an expiry timestamp for a delegated action type
setMaxAllowedSubaccountActionCount(address subaccount, bytes32 actionType, uint256 maxAllowedCount)Cap how many actions a subaccount can perform
setSubaccountAutoTopUpAmount(address subaccount, uint256 amount)Configure automatic native-token top-ups for the subaccount
setIntegrationId(address subaccount, bytes32 integrationId)Bind the subaccount to an integration identifier

Order functions

SubaccountRouter only exposes delegated order actions:

FunctionPurpose
createOrder(address account, CreateOrderParams params)Create an order for the main account
updateOrder(bytes32 key, ...)Update a pending order
cancelOrder(bytes32 key)Cancel a pending order

Integration notes

  • Subaccount order actions are gated by Keys.SUBACCOUNT_ORDER_ACTION.
  • The router validates the main account's integration id before handling the action.
  • For swap and increase orders, the router transfers the main account's collateral into OrderVault through the core Router plugin mechanism.
  • Auto top-up uses the main account's WNT allowance and balance, then unwraps native token to the subaccount. The top-up amount is capped to the native tokens actually spent on gas plus execution fee.

For the exact implementation, see SubaccountRouter.sol.

Gelato relay routers

GMX exposes two relay entry points for gasless order management:

ContractPurpose
GelatoRelayRouterGasless create / update / cancel / batch order flow for the main account
SubaccountGelatoRelayRouterGasless delegated order flow for subaccounts, plus removeSubaccount

Supported actions

FunctionGelatoRelayRouterSubaccountGelatoRelayRouter
batch(...)YesYes
createOrder(...)YesYes
updateOrder(...)YesYes
cancelOrder(...)YesYes
removeSubaccount(...)NoYes

RelayParams structure

Relay calls share the IRelayUtils.RelayParams envelope:

  • oracleParams: optional oracle data for GMX-based fee swaps
  • externalCalls: optional external swap / call bundle
  • tokenPermits: optional EIP-2612 permits
  • fee: feeToken, feeAmount, and optional feeSwapPath
  • userNonce: replay-protection nonce chosen by the user
  • deadline: signature expiry
  • signature: signed relay authorization
  • desChainId: destination chain id expected by the signature

Integration notes

  • Relay routers do not expose multicall or sendTokens; token movements for external calls must be declared through externalCalls.sendTokens and externalCalls.sendAmounts.
  • Relay fees are paid from the main account, not the relayer.
  • SubaccountGelatoRelayRouter additionally validates a SubaccountApproval signature and per-account nonce.
  • External calls are rejected for subaccount relay orders.

For the exact implementation, see GelatoRelayRouter.sol, SubaccountGelatoRelayRouter.sol, and IRelayUtils.sol.

Multichain routers

The multichain contracts power GMX Account flows and other cross-chain operations.

Action routers

ContractNotable surface
MultichainOrderRouterbatch, createOrder, updateOrder, cancelOrder, setTraderReferralCode, registerCode
MultichainGmRoutercreateDeposit, createWithdrawal, createShift
MultichainGlvRoutercreateGlvDeposit, createGlvWithdrawal
MultichainClaimsRouterclaimFundingFees, claimCollateral, claimAffiliateRewards
MultichainTransferRouterbridgeIn, bridgeOut, transferOut

Reader surface

MultichainReader is the cross-chain read helper. Its notable entry points are:

  • quoteReadFee(...) to estimate the LayerZero read fee
  • sendReadRequests(...) to dispatch read requests across configured chains
  • lzReceive(...) to receive LayerZero read responses and forward them to the registered originator

Integration notes

  • Multichain action routers take both account and srcChainId, because the action may originate from a different chain than the settlement chain.
  • GM and GLV multichain routers also take TransferRequests so funds can be routed into the correct vaults before the action is created.
  • Claim routes send outputs into MultichainVault first, then record the transfer for the destination receiver.
  • MultichainTransferRouter.bridgeOutFromController(...) is controller-only infrastructure for protocol-driven bridge-outs after execution, not a general user-facing entry point.
  • MultichainReader.quoteReadFee(...) is a public read helper, but sendReadRequests(...) is controller-gated and intended for authorized originators rather than general end users.
  • lzReceive(...) is part of the LayerZero receive path and not a normal end-user entry point.

For the exact implementation, see IMultichainOrderRouter.sol, IMultichainGmRouter.sol, IMultichainGlvRouter.sol, IMultichainTransferRouter.sol, MultichainClaimsRouter.sol, and MultichainReader.sol.

Next steps