trade-doc/mevnode-bot-architecture.md

Mevnode Bot Architecture

Zasada glowna

mevnode_bot nigdy nie uruchamia warstwy Solana node:

• bez agave
• bez ledger
• bez yellowstone server
• bez validator stack

mevnode_sol pozostaje jedynym hostem node-level:

• agave-validator
• yellowstone geyser plugin
• yellowstone gRPC
• plugin metrics
• lokalny RPC
• opcjonalnie pozniej RPC proxy

Schemat mevnode_bot

+--------------------------------------------------------------+
|                        mevnode_bot                           |
|                  single-node k3s only                        |
|                                                              |
|  ingress/web                                                 |
|  - frontend                                                  |
|  - api                                                       |
|                                                              |
|  trading/read                                                |
|  - yellowstone-consumer                                      |
|  - market ingest / parser                                    |
|  - dlob-worker                                               |
|                                                              |
|  trading/core                                                |
|  - strategy-engine                                           |
|  - risk-manager                                              |
|  - order-manager                                             |
|  - tx-router                                                 |
|                                                              |
|  tx paths                                                    |
|  - tpu client                                                |
|  - jito client                                               |
|  - rpc client / later rpc proxy target on mevnode_sol        |
|                                                              |
|  data                                                        |
|  - postgres                                                  |
|  - redis optional                                            |
|  - clickhouse later optional                                 |
|                                                              |
|  ops                                                         |
|  - prometheus                                                |
|  - grafana                                                   |
|  - loki optional                                             |
|                                                              |
|  platform                                                    |
|  - argo/flux                                                 |
|  - sealed-secrets or sops                                    |
|  - internal registry access                                  |
+--------------------------------------------------------------+

Przeplyw danych

Yellowstone on mevnode_sol
        |
        v
yellowstone-consumer
        |
        v
parser / ingest / dlob-worker
        |
        v
strategy-engine
        |
        v
risk-manager / order-manager
        |
        v
tx-router
   |        |        |
   v        v        v
  TPU      Jito     RPC

Namespace plan

• web
• trade
• data
• ops
• infra

Kolejnosc wdrozenia

1. web: frontend, api
2. data: postgres
3. trade: yellowstone-consumer
4. trade: strategy-engine, tx-router
5. ops: prometheus, grafana

Read i write path

Read path:

• mevnode_bot -> wg0 -> mevnode_sol:10000

Metrics path:

• mevnode_bot -> wg0 -> mevnode_sol:8999

Write path pozniej:

• mevnode_bot -> TPU/Jito
• albo mevnode_bot -> RPC proxy -> mevnode_sol:127.0.0.1:8899

Zasada architektoniczna

• mevnode_sol = source of truth dla chain access
• mevnode_bot = execution and product node

K3s object map

Namespace web

• Deployment frontend
• Service frontend typu ClusterIP
• Deployment api
• Service api typu ClusterIP
• Ingress web

Przeznaczenie:

• frontend wystawia UI
• api wystawia backend HTTP
• Ingress publikuje tylko web entrypoint

Namespace trade

• Deployment yellowstone-consumer
• Deployment dlob-worker
• Deployment strategy-engine
• Deployment risk-manager
• Deployment order-manager
• Deployment tx-router
• Service strategy-engine typu ClusterIP jesli inne komponenty maja sie do niego odwolywac
• Service tx-router typu ClusterIP tylko jesli potrzebne bedzie sterowanie po HTTP/gRPC

Przeznaczenie:

• yellowstone-consumer czyta stream z mevnode_sol
• dlob-worker robi ingest i przygotowanie danych
• strategy-engine podejmuje decyzje
• risk-manager egzekwuje limity
• order-manager sklada i nadzoruje lifecycle zlecen
• tx-router wybiera TPU, Jito albo RPC

Uwagi:

• strategy-engine, order-manager i tx-router mozna uruchamiac z hostNetwork: true, jesli bedzie potrzeba minimalizacji narzutu sieciowego
• yellowstone-consumer powinien miec Secret z x-token i endpointem 10.91.0.1:10000

Namespace data

• StatefulSet postgres
• Service postgres typu ClusterIP
• PersistentVolumeClaim dla postgres
• StatefulSet redis opcjonalnie
• Service redis typu ClusterIP
• PersistentVolumeClaim dla redis tylko jesli ma byc trwaly cache
• StatefulSet clickhouse dopiero pozniej
• Service clickhouse typu ClusterIP
• PersistentVolumeClaim dla clickhouse

Przeznaczenie:

• postgres dla stanu systemu, pozycji, filli, konfiguracji i jobow
• redis dla cache, kolejek, lockow i rate limitu
• clickhouse dla ciezszej analityki i archiwizacji eventow

Namespace ops

• StatefulSet prometheus
• Service prometheus typu ClusterIP
• Deployment grafana
• Service grafana typu ClusterIP
• Deployment promtail opcjonalnie
• StatefulSet albo Deployment loki opcjonalnie

Przeznaczenie:

• prometheus zbiera metryki z k3s i z aplikacji
• grafana daje dashboardy
• loki/promtail sa opcjonalne do logow

Namespace infra

• Deployment argocd-server albo kontrolery flux
• Deployment argocd-repo-server jesli wybierzemy Argo CD
• Deployment sealed-secrets-controller albo integracja sops
• Secret / ExternalSecret dla tokenow i kluczy

Przeznaczenie:

• GitOps sync z Gitea
• zarzadzanie sekretami
• bootstrap aplikacji i manifestow

Service exposure rules

• tylko frontend i api wychodza przez Ingress
• postgres, redis, clickhouse, strategy-engine, tx-router zostaja wewnetrzne jako ClusterIP
• bez LoadBalancer
• bez publicznego wystawiania komponentow tradingowych
• yellowstone-consumer nie potrzebuje publicznego Service

Storage rules

• postgres na trwałym wolumenie
• clickhouse tylko na szybkim lokalnym storage
• redis bez PVC jesli ma byc tylko cache
• aplikacje tradingowe jako stateless Deployment, jesli stan trzymamy w postgres

Config and secrets

• ConfigMap dla endpointow, feature flags i runtime config
• Secret dla:
  • tokenu Yellowstone
  • kluczy API
  • danych do postgres
  • danych do Jito
  • kluczy signing/delegate

Kolejnosc wdrozenia w k3s

1. infra: GitOps i secrets
2. data: postgres
3. web: frontend, api, Ingress
4. trade: yellowstone-consumer
5. trade: strategy-engine, risk-manager, order-manager
6. trade: tx-router
7. ops: prometheus, grafana