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
| Function | Purpose |
|---|---|
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:
| Function | Purpose |
|---|---|
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
OrderVaultthrough the coreRouterplugin 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:
| Contract | Purpose |
|---|---|
GelatoRelayRouter | Gasless create / update / cancel / batch order flow for the main account |
SubaccountGelatoRelayRouter | Gasless delegated order flow for subaccounts, plus removeSubaccount |
Supported actions
| Function | GelatoRelayRouter | SubaccountGelatoRelayRouter |
|---|---|---|
batch(...) | Yes | Yes |
createOrder(...) | Yes | Yes |
updateOrder(...) | Yes | Yes |
cancelOrder(...) | Yes | Yes |
removeSubaccount(...) | No | Yes |
RelayParams structure
Relay calls share the IRelayUtils.RelayParams envelope:
oracleParams: optional oracle data for GMX-based fee swapsexternalCalls: optional external swap / call bundletokenPermits: optional EIP-2612 permitsfee:feeToken,feeAmount, and optionalfeeSwapPathuserNonce: replay-protection nonce chosen by the userdeadline: signature expirysignature: signed relay authorizationdesChainId: destination chain id expected by the signature
Integration notes
- Relay routers do not expose
multicallorsendTokens; token movements for external calls must be declared throughexternalCalls.sendTokensandexternalCalls.sendAmounts. - Relay fees are paid from the main account, not the relayer.
SubaccountGelatoRelayRouteradditionally validates aSubaccountApprovalsignature 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
| Contract | Notable surface |
|---|---|
MultichainOrderRouter | batch, createOrder, updateOrder, cancelOrder, setTraderReferralCode, registerCode |
MultichainGmRouter | createDeposit, createWithdrawal, createShift |
MultichainGlvRouter | createGlvDeposit, createGlvWithdrawal |
MultichainClaimsRouter | claimFundingFees, claimCollateral, claimAffiliateRewards |
MultichainTransferRouter | bridgeIn, bridgeOut, transferOut |
Reader surface
MultichainReader is the cross-chain read helper. Its notable entry points are:
quoteReadFee(...)to estimate the LayerZero read feesendReadRequests(...)to dispatch read requests across configured chainslzReceive(...)to receive LayerZero read responses and forward them to the registered originator
Integration notes
- Multichain action routers take both
accountandsrcChainId, because the action may originate from a different chain than the settlement chain. - GM and GLV multichain routers also take
TransferRequestsso funds can be routed into the correct vaults before the action is created. - Claim routes send outputs into
MultichainVaultfirst, 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, butsendReadRequests(...)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
- Contract addresses for live deployments
- ExchangeRouter for standard order, deposit, withdrawal, and shift flows
- GlvRouter for GLV request flows
- Known issues for integration caveats and operational risks