# Analysis Request: Maker vs Taker for Hedging Optimization

**Status:** Completed
**Date:** 2025-12-20
**Priority:** Medium

---

## 1. User Description & Query
**Goal:** Determine if using **Maker (Alo)** orders instead of **Taker (Ioc)** orders for "safe" rebalancing (in the middle of the range) would improve PnL.
**Hypothesis:** Maker orders earn rebates (or pay lower fees) and capture the spread, but risk non-execution (delta drift). Taker orders pay fees and cross the spread but guarantee immediate hedging.

### Specific Questions
1.  What data is needed to evaluate this trade-off?
2.  How to measure the "Cost of Waiting" (Delta Drift)?

---

## 2. Agent Summary
*   **Objective:** Define the data requirements to backtest/simulate a "Maker Hedging Strategy."
*   **Current State:** `clp_hedger.py` predominantly uses Taker orders (`Ioc`) for rebalancing to ensure the hedge matches the Uniswap delta instantly. Maker orders (`Alo`) are only used for passive closing.

## 3. Main Analysis

### 3.1 The Trade-off Equation
To know if Maker is better, we must solve:
$$ \text{Gain} > \text{Loss} $$
$$ (\text{Spread Capture} + \text{Fee Rebate}) > (\text{Delta Drift Cost} + \text{Opportunity Cost}) $$

*   **Spread Capture:** Selling at Ask vs. Selling at Bid.
*   **Fee Rebate:** Hyperliquid pays rebates for Maker orders (e.g., 0.02%) vs charging Taker fees (e.g., 0.035%). Total swing ~0.055%.
*   **Delta Drift:** While your Maker order sits on the book, the price moves. Your Uniswap LP delta changes, but your hedge delta doesn't. You are "under-hedged" or "over-hedged" for those seconds.

### 3.2 Required Data for Simulation

To simulate this, we cannot just look at OHLC candles. We need **Tick-Level Order Book Data**.

#### A. Order Book Snapshots (The "Opportunity")
*   **Metric:** **Bid-Ask Spread Width** over time.
    *   *Why:* If the spread is 0.01% (tight), Maker offers little gain. If it's 0.1% (wide), capturing it is huge.
    *   *Data:* `timestamp`, `best_bid`, `best_ask`.

#### B. Trade Flow / Fill Probability (The "Risk")
*   **Metric:** **Time to Fill (at Best Bid/Ask)**.
    *   *Why:* If you place a Maker buy at Best Bid, how long until someone sells into you? 1 second? 1 minute?
    *   *Data:* You need a recording of **all public trades** on Hyperliquid to match against your theoretical order price.

#### C. Price Velocity (The "Drift")
*   **Metric:** **Price Change per Second** during the "Wait Time".
    *   *Why:* If you wait 5 seconds for a fill, and ETH moves 0.2%, you just lost 0.2% in unhedged exposure to save 0.05% in fees. Bad trade.

### 3.3 Implemented Solution: Shadow Order Simulator
The system now runs a real-time simulation engine to verify Maker feasibility without risking capital.

#### Mechanism:
1.  **Creation:** Every successful Taker trade (`Ioc`) triggers the creation of a "Shadow Order" at the passive price (Bid for Buy, Ask for Sell).
2.  **Dynamic Timeout:** The "Time to Live" for the simulation is inversely proportional to volatility (`calculate_volatility()`):
    *   **Low Vol (Quiet):** Wait up to **60s**.
    *   **High Vol (Fast):** Timeout after **10s**.
    *   *Rationale:* In fast markets, if a fill isn't immediate, the price has likely moved too far, making a Maker strategy dangerous.
3.  **Verification:** The main loop checks these shadow orders every tick against current `Ask` (for Buy) or `Bid` (for Sell) prices to confirm if a fill *definitely* would have occurred.

#### Data Captured:
*   `[SHADOW] SUCCESS`: Maker order would have filled (capturing spread + rebate).
*   `[SHADOW] FAILED`: Price ran away (Taker was the correct choice to prevent delta drift).

## 4. Risk Assessment
*   **Risk:** **Adverse Selection.** Market makers (bots) are faster than you. They will only fill your order when the market is moving *against* you (e.g., you are buying, price is crashing).
    *   *Mitigation:* Analyze "Time to Success" logs. If successes only happen at the very end of the 60s window, the "Drift Cost" might exceed the "Spread Gain."

## 5. Conclusion
**Recommendation:**
1.  **Monitor Logs:** Let the simulator run for 48-72 hours across different market regimes (Weekend vs. Weekday).
2.  **Decision Metric:** If Success Rate > 80% and Avg Fill Time < 15s, proceed to implement a "Passive First" hedging mode for the safe center of the CLP range.

## 6. Implementation Plan
- [x] **Step 1:** Update `clp_hedger.py` to fetch and log `Bid` and `Ask` explicitly during execution.
- [x] **Step 2:** Implement `check_shadow_orders` and state management in `ScalperHedger`.
- [x] **Step 3:** Implement dynamic timeout logic based on rolling StdDev.