TWAP Execution — Step by Step

1) Enqueue & Ordering

  1. Sell requests are enqueued by join time. Earlier joins execute first, regardless of tier (e.g., a 24h exit joined earlier executes before a later 6h join).
  2. Each request is split into a sequence of TWAP slices scheduled for execution in upcoming intervals.

2) Interval Scheduling & Execution

  1. Execution runs in 30-second intervals with randomised firing within each interval to reduce predictability.
  2. All slices scheduled for the current interval form a batch (e.g., A1, B1, C1).
  3. The batch is executed atomically at the protocol level: if any slice fails, the entire batch for that interval fails.
  4. Previously up until now, there was a max cap of a maximum amount of orders that can be executed in one interval. this was done to prevent our execution reaching a block gas limit etc. However after further consideration this approach has one fatal flaw in that if we experience heavy periods of user sell volume, then user orders would be pushed out into future interval windows that have. capacity. this is theoretically fine, but if we faced a scenaio where our sell volume was too high, it could mean that user orders would be pushed so far in the future that we would essentialy have a constant and infinitely backlog of orders to process which could have unfavourable side effects. To mitigate this we have decided to remove the cap limit and just delegate the extra demand to the backend in cases of busy periods…….tbc.

3) Failure Handling & Retry Stacking

  1. Because the protocol is the only seller, all sells are guaranteed to execute once queued. There is no risk of user error, frontrunning, or skipped orders from Bandits.Fun's side.
  2. If a batch (A, B, C) is scheduled for an interval and one transaction fails (e.g., B fails), then the entire batch (A, B, C) fails together.
  3. The failed batch is retried in the next interval as a block (A1, B1, C1), ahead of any new orders queued for that interval (A2, B2, C2).
  4. Failures can only occur due to chain-level issues (congestion, gas exhaustion, block reorgs). Within Bandits.Fun’s contracts, execution is deterministic.
  5. To prevent indefinite backlogs, a maximum of 100 slices can be stacked in retries.

4) Cancellations & Finalization

  1. Cancellations are allowed and are beneficial because they reduce sell pressure.
  2. If a cancellation arrives after a slice has been queued in the current interval, it takes effect from the next interval onward. The already-queued slice for the current interval cannot be cancelled.
  3. If a cancellation arrives before the protocol queues that slice in the current interval, it takes effect immediately and the slice is not executed.