Files
uniswap_auto_clp/todo/fishing_orders.md
DiTus b22fdcf741 refactor: Standardize CLP Manager and Hedger modules & cleanup
- **clp_manager.py**: Renamed from 'uniswap_manager.py'. Standardized logic for Uniswap V3 liquidity provision.
- **clp_hedger.py**: Renamed from 'unified_hedger.py'. Consolidated hedging logic including Delta Calculation fixes, EAC (Edge Avoidance), and Fishing order implementation.
- **Cleanup**: Removed legacy 'aerodrome' folder and tools.
- **Monitoring**: Added Telegram monitoring scripts.
- **Config**: Updated gitignore to exclude market data CSVs.
2025-12-31 11:09:33 +01:00

5.2 KiB

[Feature Name / Analysis Topic] - fishing orders

Status: in progress Started: 2025/12/23 Last Updated: [YYYY-MM-DD] Tags: [Tag1, Tag2]


1. Origin & Context (The "Why")

This section captures the inception of the idea. What was the problem, and what was the initial vision?

  • Goal: create additional reveniue, increase TotPnL,
  • Initial State: currently we are under the water in total (clp position+fees+ TotPnL if closed hedge) ~$10-20, after 24h (clp position 2000, range +/-1%, fees $5)
  • Trigger: to make a hedger real delta-zero to clp position
  • Original Hypothesis: make small reveniue will help with it

2. Chronological Evolution (The Journey)

A living diary of the process. Add new entries top-down as the feature evolves. This is the story of "How we got here".

📅 Entry 1: 2025-12-23 - Initial Implementation

  • Objective: Implement a "Fishing" mechanism to capture Maker rebates and reduce hedge size at break-even prices.
  • Investigation:
    • Findings: Identified that when the price is in the "Safe Zone" (near entry), the bot sits idle. This is an opportunity to place resting Maker orders to "fish" for better entries/exits than standard Taker rebalances.
  • Current Implementation:
    • Logic: Places a Maker BUY order (Alo - Add Liquidity Only) at the hedge_entry_price when current market price is above entry.
    • Size: 10% of the target hedge size (FISHING_ORDER_SIZE_PCT = 0.10).
    • Management: The order is tracked via self.fishing_oid and is automatically cancelled before any standard rebalance trade to avoid size conflicts.
  • Decision: Start with a conservative 10% size and only for closing/reducing the hedge (Buy-to-Close when price is above entry) to validate the "Maker fill" probability without over-exposing.

📅 Entry 2: 2025-12-23 - Analysis of Symmetric Fishing (Bottom-Side)

  • Objective: Analyze the potential of adding a "Sell" fishing order when price is below entry (Symmetric Grid).
  • Investigation:
    • Scenario: Price is 1900 (Down). Entry is 2000. Hedger is Short.
    • Logic: A Limit SELL at 2000 is a valid Maker order (Above current price).
    • Effect: If filled, it increases the Short position at 2000. Since the neutral target at 2000 is fixed, this results in being slightly "Over-Hedged" (Short Delta) at Entry.
    • Strategic Value: This creates a "Mean Reversion" or "Grid" effect around the entry.
      • Top Side (Buy at Entry): Profitable if price drops to Entry and bounces up.
      • Bottom Side (Sell at Entry): Profitable if price rises to Entry and rejects down.
    • Verdict: This is beneficial. It helps offset hedging costs (which typically lose money in chop) by actively trading the chop around the entry price.
  • Decision: Implement the symmetric bottom-side fishing order.
    • If Price < Entry: Place Maker SELL at Entry.
    • If Price > Entry: Place Maker BUY at Entry.

📅 Entry 3: 2025-12-23 - Implementation of Symmetric Fishing

  • Action Taken: Modified clp_hedger.py to allow fishing orders on both sides of the entry price.
  • Result:
    • When Price > Entry: Places Maker BUY at Entry (Reduce Short).
    • When Price < Entry: Places Maker SELL at Entry (Increase Short).
  • Safety Features:
    • Added a 0.1% price buffer (dist_pct > 0.001) to prevent placing orders too close to the market price, which could result in unintended Taker trades or API rejections for Alo orders.
    • Maintains the existing 10% size restriction to ensure fishing doesn't drastically warp the delta profile.

3. Final Technical Solution (The "How")

The consolidated, final design documentation.

3.1 Architecture & Logic

  • Core Components: ScalperHedger class in clp_hedger.py.
  • Data Flow:
    1. Bot checks for active standard rebalance orders. If none exist, it enters "Fishing Mode".
    2. Compares current_mid_price against the hedge_entry_price from the exchange.
    3. Determines side: BUY if price is above entry, SELL if price is below entry.
    4. Places an Alo (Add Liquidity Only) Limit order at the exact hedge_entry_price.
  • Configuration:
    • FISHING_ORDER_SIZE_PCT = 0.10: Size of the fishing order relative to the current target hedge.

3.2 Key Constraints & Edge Cases

  • Safe Zone Only: Only active when no other orders are pending.
  • Rebalance Priority: Automatically cancelled before any rebalance trade to avoid over-exposure.
  • Maker Buffer: Only placed if market price is >0.1% away from entry to ensure Maker status.

4. Retrospective (The "Cookbook" of Fails & Ups)

Summary of lessons learned. "Read this before touching this code again."

What Failed (Pitfalls to Avoid)

  • Trap: [Don't try doing X, because Y will happen.]
  • False Assumption: [We thought Z was true, but it wasn't.]

What Worked (Success Factors)

  • Key Insight: [The breakthrough was...]
  • Design Pattern: [This specific pattern proved robust.]

5. Artifacts & References

  • Affected Files:
    • [path/to/file.py]
  • Commits: [git hash or description]
  • External Links: [URLs]