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)

RPC box ma być “lean”: na bare metalu uruchamiamy tylko Solana RPC + minimum infrastruktury (VPN, firewall, monitoring).
Drift/DLOB i reszta “biznesu” na VPS: tam są publishery DLOB, Redis, warstwa persistence do Postgresa, DB, API, UI i executor.
Vast = model plane: trening (i ewentualnie inference) robimy na GPU, ale Vast nigdy nie dostaje kluczy ani tokenów do środków.
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).