# Analysis Request: Implement Shadow Order Verification

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

---

## 1. User Description & Query
**Goal:** Verify if a Maker order (at the opposite side of the book) *would* have been filled if we had used it instead of a Taker order.
**Mechanism:** 
1.  When a Taker trade executes, record a "Shadow Order" at the *passive* price (e.g., if Taker Buying at Ask, Shadow Buy at Bid).
2.  Check the market for the next 15 seconds.
3.  If price crosses the Shadow Price, log "Success". If 15s passes without fill, log "Failed".

## 2. Agent Summary
*   **Objective:** Implement a lightweight "Shadow Order Simulator" inside `clp_hedger.py`.
*   **Key Logic:**
    *   `Shadow Buy` at $3000 (Current Bid). *Fills if Future Ask <= $3000.*
    *   `Shadow Sell` at $3001 (Current Ask). *Fills if Future Bid >= $3001.*
    *   **Wait Time:** 15 seconds max.

## 3. Main Analysis

### 3.1 Logic Changes in `clp_hedger.py`

#### A. Data Structure
Add `self.shadow_orders` list to `ScalperHedger`.
```python
self.shadow_orders = [
    {
        'id': 'shadow_123',
        'side': 'BUY',
        'price': 3000.0,
        'created_at': 1700000000,
        'expires_at': 1700000015
    }
]
```

#### B. Creation Trigger
Inside the `if oid:` block (successful Taker trade):
1.  Determine **Passive Price**:
    *   If Taker BUY -> Passive Price = `levels['bid']` (Best Bid).
    *   If Taker SELL -> Passive Price = `levels['ask']` (Best Ask).
2.  Append to `self.shadow_orders`.

#### C. Verification Loop
Inside the main `while True` loop:
1.  Iterate through `self.shadow_orders`.
2.  **Check Fill:**
    *   Shadow BUY fills if `current_ask <= shadow_price`. (Someone sold into our bid).
    *   Shadow SELL fills if `current_bid >= shadow_price`. (Someone bought our ask).
3.  **Check Expiry:** If `now > expires_at`, mark as FAILED (Price ran away).
4.  **Log & Remove:** Log the result (`[SHADOW] SUCCESS/FAIL`) and remove from list.

### 3.2 Technical Trade-offs
*   **Pros:** Real-time, empirical data on "Maker Feasibility" without risking capital.
*   **Cons:** Slight memory usage (negligible). Requires accurate `levels` data every loop.

## 4. Conclusion
**Recommendation:** Proceed with implementation. This provides the exact "Cost of Waiting" vs "Gain from Spread" data requested.

## 5. Implementation Plan
- [ ] **Step 1:** Initialize `self.shadow_orders` in `__init__`.
- [ ] **Step 2:** Add `check_shadow_orders(levels)` method.
- [ ] **Step 3:** Call `check_shadow_orders` in main loop.
- [ ] **Step 4:** Record new shadow order after `place_limit_order` (Taker) success.