GmxV2 CauldronV4

Cauldrons supporting GMX V2 GM Markets

The GMXV2 Cauldron V4 is a customized version of Cauldron V4. The custom part stems from GMXV2's deposits and withdrawals lacking atomicity. In order to still be able to safely interact with GM Markets, the Cauldron V4 has been adapted in a few key aspects:

  • An OrderAgent contract will create an orderRouter proxy contracts specific to the user, for each interaction with GMX. This contract will send the deposit order to GMX, receive the GM tokens from GMX and send them back to the cauldron via a callback function called by GMX's DepositHandler, with the opposite happening for withdrawals.

  • The Cauldron's solvency check is updated to take into account a pending order in the Proxy, on top of the regular collateral (whether the order succeeds and becomes GM tokens or fails remains as USDC in the order, it is collateral that is backing MIM)

  • The Liquidation process is updated to take into account the orderProxy's state, closing open-orders and retrieving USDC from the orderProxy back to the Cauldron.

You can find the full contract code here.

GmxV2 CauldronV4

✨ setOrderAgent | New in GmxV2 CauldronV4

This function sets the order agent for the contract. function setOrderAgent(IGmCauldronOrderAgent _orderAgent) public onlyMasterContractOwner





The new order agent to set.

♻️ _isSolvent | updated for GmxV2 CauldronV4

Concrete implementation of isSolvent. Includes a second parameter to allow caching exchangeRate.

function _isSolvent(address user, uint256 _exchangeRate) internal view override returns (bool)

It is updated in the GmxV2 CauldronV4 contract to take into account the value of the open order to the solvency check. This is because during the leverage cycle, we will borrow MIM and then create an order, that will be filled by another transaction. For the first transaction to suceed, it needs to pass the solvency check and therefore the check includes the value of the newly created order.

♻️ _additionalCookAction | updated for GmxV2 CauldronV4

Adds 3 new cook actions to the cook() function, allowing them to be called as part of an atomic bundle of different steps.

  • ACTION_WITHDRAW_FROM_ORDER: Makes sure an order exists, then calls withdrawFromOrder on it. Used during deleverages after GMX sent the USDC back to the order.

  • ACTION_CREATE_ORDER: Makes sure no order exists, then creates one with the decoded parameters using orderAgent.createOrder. Used for leverages or deleverages in order to interact with GMX.

  • ACTION_CANCEL_ORDER: Makes sure an order exists, then calls cancelOrder() to cancel it. Used when the order failed to restart the process from scratch or during liquidations when an order is in progress.

♻️ liquidate | updated for GmxV2 CauldronV4

Handles the liquidation of users' balances when their amount of collateral is too low. function liquidate(address[] memory users, uint256[] memory maxBorrowParts, address to, ISwapperV2 swapper, bytes memory swapperData) public virtual override




address[] memory

Array of user addresses.


uint256[] memory

Maximum borrow parts for each user.



Receiver address in open liquidations.



Swapper contract address.


bytes memory

Additional data for

the swapper.

This function has been updated to cancel any open order and sending the short token (USDC) back to the liquidator.

✨ closeOrder | new in GmxV2 CauldronV4

Closes an order for a given user. Only callable by the order itself. This makes the user's order address 0x0[…] effectively closing it, and removes it from the mapping of blacklisted callees. Newer orders for this same user will be a handled by a new order address.

function closeOrder(address user) public





Address of the user.

GmxV2 OrderAgent & RouterOrder

The GmxV2CauldronV4 relies on an OrderAgent and RouterOrders. More information about these periphery contracts bellow:

pageGMX V2 OrderAgent & RouterOrder

Last updated