80 lines
4.6 KiB
Markdown
80 lines
4.6 KiB
Markdown
# 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.
|