BD Hedge Separation PiX Strategy

Direct answer: what this strategy is now

Compact side-run evidence — exciting, but not promoted yet

This section summarizes the first local compact side-run performed on 3 June 2026. It is useful because it tested the idea across multiple regenerated synthetic 1m universes, but it is still a small research pass, not a full standard/deep validation.

Newest v1.0 finding: direct mega snap-average works, but only by risk profile

The v1.0 arena tested the direct version of the idea: wait for an adverse move and stabilization, snap-average the losing side to a much larger total size, close the excess near small price profit, and leave a smaller survivor core.

New manual method: re-anchor before rescue

This is the important BD manual move that was not fully present in v1.0. When one leg becomes the bad leg, do not always start adding immediately. Sometimes close the bad leg, reopen it closer to current price, and repeat until enough long/short entry separation exists. Only then decide whether a huge add is justified.

Risk profiles — the arena must choose numbers separately

This is the corrected design principle. BD may sometimes prefer max risk with a tiny wallet, and sometimes prefer maximum survivability. The arena must not collapse those into one “best” setting.

v1.2 validation pass — the arena fixed the proof chain

v1.1 was useful because it found both a real signal and a measurement bug. v1.2 is the corrected run: the master completed, the feed-forward/event-preservation audit passed, and re-anchor/mega-rescue flags no longer disappear after promotion.

v1.3-real1m deep optimizer — running, not final

v1.2 answered the proof-chain question. v1.3 is now asking the harder question: do any HSR PiX settings survive real BTC/ETH/SOL 1-minute candles, matched controls, and realistic cost assumptions?

What v1.2 cinched — and what must be tested next

v1.2 answered the measurement-integrity question. It did not answer the real-market microstructure question.

1. Core intuition

The strategy does not try to predict direction at the start. It starts neutral: long and short are both open. The edge, if it exists, must come from position management: how the losing side is rescued, how much size is added, when excess size is closed, and how the winning side is trailed.

2. Market and testing assumptions

3. Full state machine

4. Accounting formulas

5. Loss-trigger ladders — when to add

The loss ladder answers only one question: when should the losing side be allowed to add?

6. Add sizing — how much to add

This is one of the most important distinctions. The arena must test PiX and Fibonacci not only for where loss triggers happen, but also for how much size is added or targeted.

7. Core keep — what remains after rescue

After a rescued side reaches its escape trigger, it closes excess size. The key question is: how much should remain?

core_keep = base_qty

core_keep = base × 2^(L-1)

core_keep = base × PiX(L)

8. Profit exits and trailing logic

if rescued_side_roe >= escape_tp_roe:
    close_qty = current_qty - core_keep_qty

+200% ROE activation → stop/lock at +100%
+400% ROE activation → stop/lock at +300%
+500% ROE activation → stop/lock at +400%

9. Collapsed manual SOL working table

10. What PiX is doing here

-200, -314.16, -493.48, -775.16, -1217.61, -1912.43...

11. Standalone arena design

This should be a separate Python arena for this one recipe. The big v0.9 arena can be used for infrastructure ideas — resume, workers, reporting — but this strategy should not be tangled into the broad arena yet.

12. Multi-universe anti-overfit rule

13. Risk model and audit requirements

14. Strategy pseudo-code

for each scenario_universe:
    generate 1m paths constrained to real SOL daily OHLC
    audit daily reconstruction == exact

for each config:
    open LONG base_qty at P0
    open SHORT base_qty at P0

    for each 1m bar:
        choose conservative intrabar path

        for side in [LONG, SHORT]:
            update avg_entry, qty, ROE, unrealized, margin, liq_buffer

            if side is adverse and reanchor_trigger_hit:
                if profile_allows_reanchor and trend_or_flat_gate_passes:
                    close losing leg and record realized reanchor loss
                    reopen after configured delay closer to current price
                    update entry separation and whipsaw metrics

            if entry_separation_target_hit and huge_add_trigger_hit:
                add_qty = profile_bounded_huge_add(side, target_total_mult)
                add only if wallet/silo/risk caps allow
                update avg_entry, rescue level, and mega_rescue_events

            if side is adverse and next_loss_trigger_hit and not in reanchor branch:
                add_qty = add_sizing_rule(side, level, sequence_family)
                add only if risk caps allow
                update avg_entry and rescue level

            if side is rescued and escape_trigger_hit:
                core = core_keep_rule(deepest_rescue_level)
                close excess qty down to core
                record realized PnL

            if side is strongly profitable:
                update profit_peak
                create/update tranche trailing locks

            if trailing lock hit:
                close configured tranche
                protect core unless testing protect_core=false

    final_mtm = realized_pnl + ending_unrealized_pnl
    write row with risk, rescue, margin, and control metrics

15. What success would look like

16. Builder checklist — next real-1m validator