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
Parameters
_orderAgent
IGmCauldronOrderAgent
The new order agent to set.
♻️ _isSolvent | updated for GmxV2 CauldronV4
Concrete implementation of isSolvent
. Includes a second parameter to allow caching exchangeRate
.
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
Parameters
users
address[] memory
Array of user addresses.
maxBorrowParts
uint256[] memory
Maximum borrow parts for each user.
to
address
Receiver address in open liquidations.
swapper
ISwapperV2
Swapper contract address.
swapperData
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.
Parameters
user
address
Address of the user.
GmxV2 OrderAgent & RouterOrder
The GmxV2CauldronV4 relies on an OrderAgent and RouterOrders. More information about these periphery contracts bellow:
GMX V2 OrderAgent & RouterOrderLast updated