## GMX Order Execution: From Trigger to Completion (DAI -> WETH Example) This lesson details the execution phase of a GMX swap order after it has been created by a user. We'll examine the specific scenario where a user previously set up an order to swap DAI into WETH, using USDC as an intermediary token (DAI -> USDC -> WETH), and deposited the necessary DAI and ETH execution fee. The focus here is on how a keeper triggers the execution and the subsequent flow of tokens and function calls between GMX smart contracts. **Key Participants and Contracts:** * **User:** The originator of the swap order who deposited the initial DAI and the ETH execution fee. They are the final recipient of the swapped WETH (or ETH). * **Keeper:** An authorized entity within the GMX ecosystem that monitors pending orders. When market conditions allow for an order's execution, the keeper triggers the process and receives compensation for the gas costs incurred. * **OrderHandler Contract:** The central smart contract coordinating the entire execution process. It receives the trigger from the keeper, interacts with other GMX contracts, performs swap calculations, and directs token movements. * **OrderVault Contract:** A dedicated contract holding the user's assets for a specific pending order *before* execution. In this case, it holds the user's DAI (input token) and the user's ETH (pre-paid execution fee). * **MarketToken (DAI/USDC) Contract:** A GMX liquidity pool contract specifically designated for swaps involving DAI and USDC. This particular pool type is *not* used for leverage trading positions. * **MarketToken (USDC/WETH) Contract:** Another GMX liquidity pool contract, facilitating swaps between USDC and WETH. Unlike the DAI/USDC pool, this type *can* also be used as collateral for opening long or short leveraged positions (though that functionality isn't utilized in this pure swap execution). * **Tokens:** * **DAI:** The user's initial input token. * **USDC:** The intermediary token in this swap path. * **WETH (Wrapped Ether):** The desired final output token. * **ETH (Ether):** The native blockchain token used to pre-pay the execution gas fee. **Step-by-Step Execution Flow:** The execution process unfolds as a sequence of interactions orchestrated by the `OrderHandler` contract, all within a single atomic transaction initiated by the keeper. 1. **Execution Trigger:** A **Keeper** initiates the process by calling the `executeOrder` function on the **OrderHandler** contract, identifying the specific user order to be processed. 2. **Retrieve Input Token:** The **OrderHandler** instructs the **OrderVault** to release the user's input tokens by calling its `transferOut` function. 3. **DAI Transfer to First Pool:** The **OrderVault** transfers the user's full amount of DAI to the **MarketToken (DAI/USDC)** contract. 4. **First Swap (DAI -> USDC):** The **OrderHandler**, leveraging GMX's internal swap logic, calculates the amount of USDC resulting from swapping the received DAI within the **MarketToken (DAI/USDC)** pool. It then calls `transferOut` on this first MarketToken contract. 5. **USDC Transfer to Second Pool:** The **MarketToken (DAI/USDC)** contract sends the calculated amount of USDC to the **MarketToken (USDC/WETH)** contract, preparing for the second leg of the swap. 6. **Second Swap (USDC -> WETH):** The **OrderHandler** again uses GMX's internal logic to calculate the final amount of WETH resulting from swapping the received USDC within the **MarketToken (USDC/WETH)** pool. It calls `transferOut` on this second MarketToken contract. 7. **WETH Transfer to User:** The **MarketToken (USDC/WETH)** contract sends the final calculated amount of WETH directly to the **User**'s wallet address (the owner of the order). * *Note:* If the user specified receiving native ETH instead of WETH when creating the order, the WETH would be automatically unwrapped into ETH at this stage before being sent to the user. 8. **Initiate Gas Fee Distribution:** The **OrderHandler** interacts with the **OrderVault** (likely via `transferOut` for ETH) to access the execution fee (ETH) that the user pre-paid and stored in the vault. 9. **Keeper Compensation:** A portion of the ETH execution fee is transferred from the **OrderVault** to the **Keeper**'s address as payment for initiating the transaction and covering the associated gas costs. 10. **Refund Excess Fee to User:** Any remaining ETH from the initial execution fee, after compensating the keeper, is transferred from the **OrderVault** back to the **User**'s wallet address. **Key Execution Concepts:** * **Order Lifecycle Stage:** This process covers the *execution* phase, distinct from the prior *creation* phase where the user submitted the order details and deposited funds (DAI and ETH) into the OrderVault. * **Contract Roles:** GMX employs a modular design where each contract has a specific responsibility: `OrderHandler` orchestrates, `OrderVault` secures pending assets and fees, and `MarketToken` contracts manage liquidity and perform swaps. * **Execution Fee Mechanism:** Users pre-pay for execution in ETH. This fee covers the keeper's operational costs (gas). The system ensures keepers are compensated, and any overpayment is refunded to the user, promoting efficient order execution. * **Market Routing:** The `OrderHandler` intelligently routes tokens through the appropriate `MarketToken` contracts based on the defined swap path (DAI -> USDC pool, then USDC -> WETH pool). * **Atomicity:** The entire sequence, from the keeper's trigger to the final transfers, occurs within one blockchain transaction. If any step fails (e.g., insufficient liquidity, high slippage), the whole operation reverts, ensuring funds are not partially swapped or lost mid-process. **Clarification:** * **Origin of Funds in OrderVault:** The DAI (to be swapped) and ETH (for execution fee) held by the `OrderVault` at the start of this process were deposited by the **User** during the initial order creation step.