# Strategia: eskalacja horyzontu (1m → 5m → 15m → 30m → 1h) z bramkami ryzyka i kosztów

Cel: jeżeli trade nie domyka celu w krótkim oknie (np. **1m**), możemy **kontrolowanie** przejść na dłuższy horyzont (**5m/15m/30m/1h**) *bez wpadania w “przetrzymanie straty”*.

Klucz: to ma działać jako **state machine** z twardymi bramkami (gates), a nie jako “zostawię i zobaczę”.

---

## 1) Model: “czas na realizację celu” + eskalacja okna

### Parametry (na start)
- `target_bps` albo `target_usd` (np. +3 bps, +6 bps…)
- `ttl_per_mode` (time-to-live per tryb):
  - `1m`: 60–120 s
  - `5m`: 5–10 min
  - `15m`: 15–30 min
  - `30m`: 30–60 min
  - `1h`: 1–3 h

### Zasada
Jeśli w danym trybie **nie osiągniesz celu w TTL**, to:
- albo **zamykanie**,
- albo **eskalacja** do wyższego okna — *tylko* jeśli spełnione są bramki (ryzyko/koszty/struktura).

---

## 2) Bramki (gates) — kiedy eskalacja jest dozwolona

### Gate RISK (twarde)
Jeśli którykolwiek warunek jest niespełniony → **wyjście teraz** (close now).

Przykładowe progi:
- `health >= 0.70`
- `margin_ratio >= 0.15..0.20` (zależnie od dźwigni)
- odległość do `liq_price` >= `X%` albo >= `k * ATR`
- `max_drawdown` w oknie bieżącym nie przekracza limitu

### Gate COSTS (twarde)
- `close_now_cost_usd` nie “zjada” potencjału (np. koszty nie mogą przekroczyć `target_usd` albo `target_bps`)
- przy dłuższych trybach (30m/1h) uwzględnij wpływ funding:
  - `funding_expected(next_window)` nie dominuje nad edge

### Gate STRUCTURE / EDGE (miękkie, ale zalecane)
Przykłady:
- trend/edge na wyższym oknie nie jest przeciw (np. 5m dla eskalacji 1m→5m)
- spread/slippage z DLOB nie rosną anormalnie

---

## 3) Logika przejść (state machine)

Stan początkowy: `mode=1m`.

Jeżeli `ttl_expired` i `target_not_hit`:
- jeśli `risk_ok && costs_ok && structure_ok` → awans do następnego trybu,
- inaczej → `close_now`.

Przejścia:
- `1m` → `5m`
- `5m` → `15m`
- `15m` → `30m`
- `30m` → `1h`

Ważne: awans = **zmiana reżimu** (inne TTL/target/gates), a nie “przeciąganie”.

---

## 4) Pułapka i dwa “hamulce”

Pułapka:
> “nie poszło w 1m, to poczekam 5m, jak nie to 15m…” → swing bez planu

### Hamulec A: limit eskalacji
- max 1–2 awanse na trade (np. `1m→5m→15m` i koniec)

### Hamulec B: limit straty per tryb
- jeśli w trybie 1m strata przekroczy `stop_1m` → wyjście
- nie wolno “przenosić” tej samej straty w nieskończoność do 1h

---

## 5) Jak to zaszyć w naszym backendzie (worker + API)

W `contract_metrics_ts` (lub w warstwie kontraktu) trzymaj:
- `mode_current`
- `mode_enter_ts`
- `ttl_s_for_mode`
- `target_bps_for_mode`
- `gates_passed`:
  - `risk: boolean`
  - `costs: boolean`
  - `structure: boolean`
- (opcjonalnie) `escalations_used` / `escalations_remaining`

### SIM: “czy eskalacja ma sens”
Endpoint typu `POST /v1/simulate/escalate` (MVP) może zwracać:
- `expected_costs` (close now / next window)
- `risk_after` (health/margin/liq)
- `assumptions` (np. BBO+extra bps, fee tier)

---

## 6) TL;DR

- Tak, eskalacja czasu ma sens **jeśli jest kontrolowana**.
- Robimy to jako **state machine** z:
  - twardym `RISK gate`,
  - twardym `COST gate`,
  - limitem eskalacji,
  - stopem per tryb.