Files
uniswap_auto_clp/todo/SHADOW_ORDER_ANALYSIS.md

2.6 KiB

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.

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.