Architektura systemu
Środowisko uruchomieniowe DIVINE Screenera w Ruście obsługuje Solanę i Robinhood Chain. Poniższy stos i progi opisują ścieżkę Solany.
Stos
| Komponent | Co robi |
|---|---|
| Dexstream | Pozyskiwanie przez WebSocket z kanału Solany od DexScreenera |
| Aegis | Kontrole czarnej listy, posiadaczy, płynności i koordynacji w Solanie |
| Solscan API | Swapy, posiadacze, salda i dane rynkowe SOL z Solscana |
| Seraphim | Transport HTTP/WebSocket, ponowienia i podszywanie się pod przeglądarkę |
| Grimoire | Baza SQLite dla sygnałów, czarnej listy i cooldownów |
| Divine | Skaner, wysyłka na Telegram, Live Activity, TUI i endpointy stanu |
Przepływ danych
- Dexstream pobiera pary tokenów Solany przez WebSocket
- Działają filtry: kapitalizacja 3–14 tys. $, minima płynności, kontrole antyspamowe
- Aegis uruchamia moduły bezpieczeństwa równolegle, korzystając z Solscana, RugChecka, stanu SQLite i lokalnych heurystyk
- Zaakceptowane sygnały trafiają na Telegram, a Live Activity odświeża zweryfikowane sygnały danymi z DexScreenera i RPC Solany
Stos bezpieczeństwa
Ścieżka Aegis w Solanie obejmuje:
- Integralność tokena przez RugCheck i zapasowe dane o posiadaczach
- Sprawdzanie czarnej listy (ponad 50 tys. portfeli)
- Analizę koncentracji posiadaczy
- Wykrywanie koordynacji oparte na Leiden
- Heurystyki papierowych rąk i nowych portfeli
- Kontrole koncentracji w blokach w Solanie
Obecne progi produkcyjne są specyficzne dla Solany, w tym limity koncentracji w blokach 60% / 65% i reguła nowych portfeli: mniej niż 6 transakcji lub wiek poniżej 3 dni.
Utrzymanie
- Środowisko w Ruście zastępujące dawny stos w Pythonie
- Cel pokrycia linii w workspace na poziomie 96% lub więcej
- Niezmienne obrazy przy wdrożeniach na VPS
- Kontenery tylko do odczytu z kontrolami stanu i sandboxingiem
- Ponowienia z backoffem na ścieżkach do Solscana, RugChecka, DexScreenera i RPC