uniswap_auto_clp/todo/MAKER_VS_TAKER_ANALYSIS.md

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

• Step 1: Update clp_hedger.py to fetch and log Bid and Ask explicitly during execution.
• Step 2: Implement check_shadow_orders and state management in ScalperHedger.
• Step 3: Implement dynamic timeout logic based on rolling StdDev.