# Baremetal RPC + VPS + Vast (Drift / DLOB / boty)

Ten folder zbiera w jednym miejscu ustalenia dot. topologii:

- **Bare metal**: prywatny Solana RPC (opcjonalnie z Geyser/Yellowstone dla feedów realtime).
- **VPS**: “app/trading box” (k3s) z DLOB, statystykami, API i executorem transakcji.
- **Vast (GPU, min 5090)**: trening transformera + ewentualnie inference, ale **bez sekretów**.

Dokumenty powiązane:

- `doc/dlob-services.md` — jak działają serwisy DLOB na VPS (k3s) i przepływ danych.
- `doc/bots.md` — architektura botów (data plane / execution plane / model plane).
- `doc/rpc/bot-executor-api.md` — minimalne endpointy i auth dla control plane / executora.
- `doc/rpc/baremetal-monitoring.md` — jakie metryki zbieramy na RPC boxie i jak to wdrażamy (IaC).
- `doc/rpc/baremetal-iac.md` — jak utrzymywać `mevnode-baremetal` jako IaC z runnera na VPS.

## Założenia (najważniejsze)

1) **RPC box ma być “lean”**: na bare metalu uruchamiamy tylko Solana RPC + minimum infrastruktury (VPN, firewall, monitoring).

2) **Drift/DLOB i reszta “biznesu” na VPS**: tam są publishery DLOB, Redis, warstwa persistence do Postgresa, DB, API, UI i executor.

3) **Vast = model plane**: trening (i ewentualnie inference) robimy na GPU, ale Vast **nigdy nie dostaje kluczy** ani tokenów do środków.

4) **Start od 2 marketów**: na początek ograniczamy DLOB do małej listy rynków, np. `PERP_MARKETS_TO_LOAD=0,75` (indeksy marketów PERP).

## Topologia (skrót)

```
                (public)
   ┌────────────────────────────────────────────────────┐
   │                 Internet / UI                      │
   │  trade-frontend + GraphQL (Hasura) + control-plane │
   └───────────────▲────────────────────────────────────┘
                   │
                   │ HTTPS (auth), brak “sign & send”
                   │
┌──────────────────┴───────────────────────────────────────────────────┐
│ VPS (k3s / trade-staging)                                             │
│                                                                       │
│  Data plane:                                                          │
│   - dlob-publisher-hot/all  →  dlob-redis                             │
│   - hot/all writers  →  Postgres  →  Hasura (GraphQL/WS)              │
│                                                                       │
│  Execution plane:                                                     │
│   - bot-executor (jedyny komponent z kluczami, podpisuje transakcje)  │
│   - trade-api (tokeny, admin ops, pomocnicze endpointy)               │
│                                                                       │
│  Monitoring: Prometheus/Grafana/Alertmanager                           │
└──────────────────▲───────────────────────────────────────────────────┘
                   │ WireGuard (private)
                   │ RPC/WS + opcjonalnie gRPC (Geyser)
┌──────────────────┴───────────────────────────────────────────────────┐
│ Bare metal (RPC box)                                                  │
│  - agave/solana-validator jako prywatny RPC (bez publicznego dostępu) │
│  - (opcjonalnie) Geyser/Yellowstone gRPC plugin                        │
│  - wireguard + firewall + chrony + eksportery                          │
└──────────────────────────────────────────────────────────────────────┘

                         (public, outbound)
┌──────────────────────────────────────────────────────────────────────┐
│ Vast (GPU, min 5090)                                                  │
│  - trening transformera na zebranych danych                            │
│  - ewentualnie inference endpoint                                      │
│  - brak sekretów (brak kluczy, brak tokenów do środków)                │
└──────────────────────────────────────────────────────────────────────┘
```

## Bare metal: co instalować i dlaczego

Minimalny zestaw (zgodnie z regułą “keep it lean”):

- **Solana RPC node** (validator w trybie RPC/non-voting).
- **WireGuard**: RPC dostępny tylko prywatnie (VPS + admin).
- **Firewall**: zablokowane porty RPC/WS na publicznym interfejsie; allow tylko na interfejsie WG.
- **Chrony**: stabilny czas.
- **Monitoring**:
  - `node_exporter` (CPU/RAM/dysk/iowait/sieć),
  - `solana-exporter` lub równoważny probe health przez RPC.
- **Higiena dysk/logów**: rotacja logów, limity journald, monitoring NVMe.

Opcjonalnie (kolejny poziom “pro”):

- **Geyser / Yellowstone gRPC**: realtime stream kont/tx/slotów (mniejsze opóźnienia niż polling).

### Geyser + Drift DLOB (praktycznie)

Jeśli uruchamiasz Yellowstone gRPC na RPC boxie, to na VPS możesz przełączyć `dlob-publisher`
na feed gRPC (zamiast Solana WS), a jednocześnie dalej trzymać prywatny dostęp po WireGuard.

- RPC HTTP (JSON-RPC): `ENDPOINT=http://<rpc_wg_ip>:8899`
- RPC WS (pubsub): `WS_ENDPOINT=ws://<rpc_wg_ip>:8900`
- Yellowstone gRPC: `GRPC_ENDPOINT=http://<rpc_wg_ip>:10000` (+ `TOKEN`, jeśli włączasz auth)

Konfiguracja DLOB (VPS) w praktyce (skrót):

- `PERP_MARKETS_TO_LOAD=0,75` (start od 2 marketów)
- `USE_ORDER_SUBSCRIBER=true`
- `USE_GRPC=true` + `GRPC_ENDPOINT` + `TOKEN` + `GRPC_CLIENT=yellowstone`
- (opcjonalnie) `DISABLE_GPA_REFRESH=true` żeby ograniczyć polling

Więcej: `doc/rpc/geyser-dlob.md`.

Uwaga o 192 GB RAM:

- Na mainnet łatwo “dobić” pamięć jeśli włączysz ciężkie indeksy kont / rozbudowane API / wielu klientów.
- Dlatego tym bardziej trzymamy RPC jako **prywatny** (mała liczba klientów: DLOB + executor + admin) i przenosimy obliczenia na VPS.

## VPS (k3s): co działa i jak jest używane

W `trade-staging` (k3s) mamy dwa krytyczne “plany”:

### Data plane (market data + statsy)

Opis szczegółowy: `doc/dlob-services.md`.

- `dlob-publisher-hot` i `dlob-publisher-all`: budują DLOB “off your RPC” i publikują snapshoty do Redis.
  - Na start ogranicz rynki hot-setu przez `PERP_MARKETS_TO_LOAD`.
- `dlob-redis`: szybki cache dla publisherów i writerów.
- `dlob-hot-redis-to-postgres-raw-writer`, `dlob-hot-postgres-to-postgres-derived-writer`, `dlob-all-redis-to-postgres-derived-writer`:
  - zapisują raw `hot` i derived `hot/all` do Postgresa,
  - Hasura wystawia te dane jako GraphQL + subscriptions.

### Execution plane (transakcje na Drift)

Opis szczegółowy: `doc/bots.md` (separation of concerns + kill switch).

- **`bot-executor`**:
  - jedyny komponent z kluczami (seed/keypair),
  - wykonuje `place/modify/cancel/close` + limity ryzyka + kill switch,
  - komunikuje się z DB (config/desired state + event log).

### Jak wystawić API na zewnątrz (propozycja)

Kluczowa zasada:

- **Nie wystawiamy publicznie “sign & send tx”**.

Wystawiamy tylko control plane:

- ustawianie `bot_config` (desired state / kill switch),
- odczyt `bot_state` / `bot_events`,
- market data / statsy przez Hasurę (GraphQL) i/lub własne read-only endpointy.

Warstwa dostępu (rekomendacja):

- Sieć: WireGuard / allowlist IP.
- Aplikacja: tokeny + scopes.
- (opcjonalnie) mTLS/HMAC między serwisami.

Executor czyta “desired state” z DB i sam podpisuje transakcje w klastrze.

## IaC (Git) dla bare metalu

Konfigurację RPC boxa (Solana RPC + Geyser + WireGuard + firewall + exporters) warto trzymać w Git
i wdrażać z VPS (np. Ansible po WireGuard).

Starter (szkielet): `infra/baremetal-solana-rpc/`.

## Vast (GPU): jak to wpinamy

Model plane wg `doc/bots.md`:

- VPS zbiera dane (features, statsy, candles, eventy) i składa dataset.
- Trening transformera na Vast (min 5090).
- Artefakty modelu wracają na VPS (lub inference zostaje na Vast), ale:
  - **Vast nie dostaje kluczy**,
  - VPS podejmuje decyzję o wykonaniu i podpisuje transakcje (executor).