# Trade Execution Logic and Retry Behavior

When executing TWAP orders, Brahma uses a structured approach to maximize the chances of successful execution while staying within user-defined parameters. Below is a breakdown of how trade execution and retries are handled:

**Slippage Handling and Retry Mechanism**

When a TWAP order is triggered, Brahma attempts execution using the following process:

1. **Initial Quote & Simulation (Try 1):**
   * Brahma begins by attempting execution using a slippage **lower than** the user-defined maximum, if possible.
   * The service progressively increases slippage through a preset ladder (e.g. 0.05%, 0.10%, 0.50%, up to the user-defined max).
   * At each step, it fetches a quote, simulates the trade, and checks if the quote would succeed.
   * Once a working quote is found within the defined slippage, it is submitted on-chain.
2. **Fallback Attempt (Try 2):**
   * If the first transaction fails *after* submission (i.e. the quote was valid during simulation but reverted during mining), a second attempt is made.
   * This second attempt uses the **user-defined maximum slippage** directly without incremental steps.
   * A new quote is fetched, simulated, and submitted for execution.
3. **Failure Condition:**
   * If the second attempt also fails (either in simulation or after submission), the order is marked as failed and no further retries are made.
   * If simulation fails even at the user-defined maximum slippage, no transaction is submitted and the order is marked as failed.

> **Important:** For Try 2 to trigger, the transaction must revert *after* passing the simulation step but *before* or during mining. This is rare and typically occurs only when slippage is extremely tight.

**Timing and Interval Execution**

* The **first order** in the TWAP sequence is executed immediately after setup.
* Subsequent orders are scheduled at fixed intervals, based on the time of the initial execution.
* For example, with a 1-minute interval:
  * Order 1 executes at time `T`
  * Order 2 is scheduled for `T + 1m`
  * Order 3 is scheduled for `T + 2m`, and so on
* While Brahma aims to initiate execution exactly at the scheduled interval, the **actual on-chain transaction** may land slightly after the target time due to retries or network delay.