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.