> For the complete documentation index, see [llms.txt](https://autopilot-5.gitbook.io/autopilot/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://autopilot-5.gitbook.io/autopilot/protocol/markdown/special-window-protocol.md).

# Special Window Protocol

Autopilot uses a defined **execution window** at the end of each epoch to ensure voting, claiming, and swapping actions are processed securely and consistently.

\
This mechanism protects against timing-based manipulation, ensures fair participation, and aligns reward distribution with the latest on-chain state across both **Base (Aerodrome)** and **Optimism (Velodrome)** networks.

***

#### 🕒 Timing Structure

Each supported protocol includes its own **Special Window** — the period when Autopilot performs all automated operations and user interactions are paused.

**Aerodrome (Base):**\
Total window length — **3 hours and 30 minutes**

* **Pre-Epoch Window:** Begins 3 hours before epoch end\
  → Deposits made during this time count toward the next epoch\
  → Withdrawals are blocked\
  → Bot operations (voting, claiming, swapping) begin
* **Post-Epoch Window:** Lasts 30 minutes after the new epoch starts\
  → Bot logic completes reward processing\
  → User actions remain paused to avoid state conflicts

**Velodrome (Optimism):**\
Total window length — **13 hours**

* **Pre-Epoch Window:** Begins 5 hours before epoch end
* **Post-Epoch Window:** Extends 8 hours after epoch start\
  The longer window ensures safe **multi-chain swaps and bridging**, allowing enough time for reward settlement between Optimism and Base networks.

This time-bound design guarantees that deposits or exits cannot interfere with reward execution mid-cycle and that all users are treated fairly within each epoch.

***

#### 🔐 Special Window Behavior

**⛔ User Actions Blocked**

* Deposits and withdrawals are disabled during each protocol’s Special Window.
* Prevents users from joining too late or exiting too early relative to reward timing.
* Enforced by:\
  `isInSpecialWindowOrFail()`

**🤖 Bot Actions Allowed**\
During this window, protocol contracts are authorized to execute automated functions:

* `vote()` — submits votes based on the live strategy model
* `claim()` and `claimBribes()` — collects all earned rewards
* `swap()` — converts all reward tokens to USDC using internal routing

All actions execute automatically and in sequence under predefined logic.

***

#### 🛠️ Snapshot & Sync

Autopilot maintains on-chain accuracy and reward integrity through:

* **Emergency Snapshots:**\
  Captures voting power and reward eligibility before user or bot actions.
* **Epoch Synchronization:**\
  If a transaction is delayed or missed, the system auto-detects and re-aligns for the next epoch, ensuring continuous participation.

***

#### 🟢 Behavior Outside the Special Window

Outside of the defined execution windows:

* Users can deposit and withdraw freely.
* All bot operations are paused.
* Strategy logic remains idle until the next window begins.

This separation ensures all on-chain operations remain deterministic, trackable, and conflict-free between epochs.

***

#### 🔄 Synchronization Logic

To maintain accurate reward calculations, Autopilot implements:

* **Per-epoch weight tracking:**\
  Stored via `total_tracked_weight[epoch_id]` to record each user’s voting power snapshot.
* **Fallback handling:**\
  If any epoch process fails or is skipped, the protocol automatically resumes in the next cycle with no user action required.
* **Snapshot before each action:**\
  Ensures all operations reference the correct state:\
  `emergencySnapshot()`