HVF Radar — Hunt Volatility Funnel scanner (crypto) — 2026-06-27

A new live page that scans the crypto universe for Hunt Volatility Funnel (HVF) patterns and reports the exact trade levels Jacques defined. This log documents what the radar is, the redesign it went through on this date, how it runs, and an honest note on what it is and is not.

(Written up 2026-06-29 from the code on disk and the running service — the build happened 2026-06-27 but hadn't been logged yet.)

1. What an HVF is (the pattern)

A funnel is a converging triangle that forms after a trend exhausts and turns. Six confirmed swing pivots define it:

• HVF (bullish): descending highs H1 > H2 > H3 with rising lows L1 < L2 < L3 — the range squeezes into a higher-low base.
• Entry: break above H3.
• Stop: price comes back below L3.
• Target: the first-leg height (H1→L1 distance) projected up from the funnel centre (the midpoint of H3 and L3).
• iHVF (bearish): the mirror — rising lows L1 < L2 < L3 capped by falling highs H1 > H2 > H3.
• Entry: break below L3. Stop: back above H3.
• Target: first-leg height projected down from the centre.

Profit % is measured entry→target, loss % is entry→stop — both from the breakout entry and before costs.

2. The redesign on this date — "forming" → "completed"

The radar started life as a forming-pattern edition (Flask on :5055, find_hvf_forming): it lit a name up while the final pivot was still developing — i.e. once H3 was in and price was pulling back toward a not-yet-confirmed L3. That fires early but is noisy: the final pivot can fail to form and the "funnel" evaporates.

On 2026-06-27 it was rewritten into the completed-pattern edition (find_hvf_completed / find_ihvf_completed, Flask on :5056). Now all six pivots H1..L3 must be confirmed before a name appears, and the row reports the ready-to-use trade levels above. The previous version is kept as the backup hvfradar.py.bak_1782564307 (14:45), and the final edit landed 14:47.

Net effect: fewer, higher-quality hits — only funnels that are actually complete and sitting at or near their breakout, rather than speculative half-formed shapes.

3. How the scan works

• Reads /root/crypto_bots/crypto_cross.db READ-ONLY (mode=ro). It does no data collection of its own — it rides on whatever exchange_universe.service has already written, so it never contends with the live DB writer.
• Universe: the 464 active rows in tracked_symbols (Bybit USDT perps).
• Timeframes: 5m / 15m / 1h / 4h. Pulls the last 400 candles per symbol/timeframe.
• Pivots: a swing high/low is confirmed only if it is the extreme within a ±10-bar window (PIVOT_WINDOW=10) — so a pivot needs 10 bars of hindsight to confirm, which is what makes a "completed" funnel real and not repainting.
• Funnel gates (same retrace discipline as Larry):
• H2 must retrace ≥ 0.61 of the first leg, H3 ≥ 0.50 of the second.
• The turn must be genuine: for HVF, L1 must be a higher low than the exhaustion low before H1 (mirror for iHVF). This rejects shapes that are just a continuation of the prior trend.
• The anchor pivot (L3 for HVF, H3 for iHVF) must be within 40 bars (MAX_AGE) of now — stale funnels are dropped.
• Ranking: rows are sorted by |to_trigger_pct| so the most imminent breakouts (and just-broken ones) sit on top. to_trigger_pct > 0 = price is still the watching side of the trigger; <= 0 = it has already broken.
• 30-second in-memory cache per timeframe.

4. The page

• Self-contained Flask app, served at /hvfradar/ (nginx → 127.0.0.1:5056).
• Same "Groovy Baby" / Austin Powers theme as the rest of the research site (hypno spiral, rainbow gradients, Bagel Fat One / Fredoka / Space Mono).
• Each row deep-links to the BYBIT TradingView perp chart (BYBIT:<SYM>.P), and shows the six pivot levels, entry/stop/target, and the profit/loss/to-trigger percentages.
• Linked from the main Big Bots homepage as the "HVF Radar" tile (k9).

5. How it runs (ops)

• hvfradar.service — Type=simple, User=root, ExecStart=/usr/bin/python3 /root/crypto_bots/hvfradar.py, Restart=always (RestartSec=10), logs to journal.
• Active and healthy — running since 2026-06-27. /health returns OK.
• Backup of the prior (forming) edition: hvfradar.py.bak_1782564307.

6. Snapshot at write-up (2026-06-29 ~10:50 SAST)

Live hit counts: 5m: 2 · 15m: 1 · 1h: 6 · 4h: 3. Top 1h hit was DASH (iHVF / short): entry 32.68, stop 34.51, target 30.10 — ~+7.9% to target vs ~2.1% risk before costs, sitting 0.37% from its trigger.

7. Honest note — what this is and isn't

• This is a discretionary screen / idea generator, not a backtested system. It surfaces clean, completed funnels at their decision point so Jacques can vet each one by hand (consistent with how we use the momentum shortlist).
• No expectancy claim is being made. The profit/loss percentages are the geometry of each setup (entry→target, entry→stop) before the mandated costs (0.055% fee + 0.03% slippage per side) — they are not realised results and there is no win-rate or profit-factor study behind them yet.
• A natural next step, if we want to treat HVF as a validated edge rather than a watchlist, would be to backtest the completed-funnel breakout on history with the standard validation rules. Now done (2026-06-29) — see 2026-06-29_hvf-breakout-backtest.md. Short version: not a validated systematic edge — the only split-validated timeframe (4h) shows a tiny, short-driven in-sample edge whose short leg collapses out of sample, and the timeframes with enough trades to matter (15m, 5m) lose after costs. It stands as a discretionary screen, not an auto-trade system — exactly as framed here.

8. Risk/Reward column on the page (2026-06-29)

Jacques asked for a R/R column. The page already carried Profit % (entry→ target) and Loss % (entry→stop), so reward-to-risk is just their ratio.

• Backend: each funnel now returns an rr field = (target move) / (stop move) (== Profit % ÷ Loss %), for both HVF and iHVF. Guarded against a zero stop distance (can't happen given the gates, but defensive).
• Table: new R/R column between Loss % and Age, colour-coded — green ≥ 2.0, neutral 1–2, red < 1.0 — so higher-quality setups stand out at a glance. Legend footnote added.
• Verified on a throwaway port (5099) first — the ratio matched on both pattern types (e.g. FIL iHVF 9.40/2.07 = 4.53; AT HVF 25.04/10.20 = 2.45) — then hvfradar.service was restarted with Jacques' OK; live and serving the column. Prior version backed up to hvfradar.py.bak_1782724037.
• Honest note: R/R is still pre-cost geometry of the setup, not a realised expectancy — same caveat as Profit %/Loss %.

Files

• /root/crypto_bots/hvfradar.py — the radar (scan + page, now with R/R).
• /root/crypto_bots/hvfradar.py.bak_1782564307 — prior "forming-pattern" edition.
• /root/crypto_bots/hvfradar.py.bak_1782724037 — pre-R/R-column version.
• Backtest: 2026-06-29_hvf-breakout-backtest.md + /root/backtest_hvf_PY-00028_290626.py.
• Data source: /root/crypto_bots/crypto_cross.db (candles, tracked_symbols), read-only. Served by hvfradar.service on :5056, nginx route /hvfradar/.