Tak. Właściwie opisałeś dużo ciekawszy system niż zwykły token scanner. Taki bot nie próbowałby zgadywać ceny na podstawie samego kontraktu, tylko budowałby reputację portfeli i sieć powiązań między tokenami.

Robinhood Chain szczególnie się do tego nadaje, bo jest EVM-compatible, ma publiczny RPC, Blockscout, a np. pons publikuje adresy swoich factory oraz event TokenLaunched, który zawiera m.in. adres tokena i deployera. Można więc pracować bezpośrednio na danych blockchainowych, zanim Dexscreener zdąży token zindeksować.

Jak powinien wyglądać Twój bot

Widzę tutaj dwa moduły.

Analyzer przyjmuje np. 20 adresów tokenów:

TOKEN A
TOKEN B
TOKEN C
...
TOKEN T

i buduje dla nich graf:

                    ┌─ TOKEN X
                    │
TOKEN A ─ DEV ─ FUNDER ─ TOKEN Y
    │       │
    │       └─ wcześniejszy TOKEN Z
    │
    ├─ EARLY BUYER #1 ─ FUNDER 2 ─ TOKEN B
    ├─ EARLY BUYER #2 ──────────── TOKEN F
    ├─ EARLY BUYER #3
    │
    └─ TOP HOLDER ──────────────── TOKEN C

Drugi moduł, Watcher, słucha nowych bloków i mówi:

Pojawił się nowy token.
Deployer jest powiązany z 3 wcześniejszymi tokenami.
2 z nich osiągnęły >$5M MC.
4 z pierwszych 20 kupujących pojawiało się wcześniej przy udanych tokenach.
Wykryto wspólnego fundera.
Koncentracja supply jest niska.
Score: 82/100.

To jest dokładnie ten rodzaj sygnału, którego Dexscreener sam w sobie Ci nie daje.

Co bot może ustalić naprawdę dobrze

Dla podanego tokena bot powinien znaleźć co najmniej:

Informacja	Czy możliwe?
kto uruchomił token	tak
contract deployer	tak
launchpad/factory	tak
portfel DEV	często tak
skąd DEV dostał ETH	tak
wcześniejsze tokeny DEV	tak
top holderzy	tak
udział Top 10/20	tak
pierwszych kupujących	tak
dokładny blok zakupu	tak
kto finansował kupujących	tak
wspólny funder wielu wallets	często tak
wcześniejsze tokeny kupujących	tak
czy te wcześniejsze tokeny odniosły sukces	tak, jeśli zdefiniujemy sukces
bundle/sybil wallets	można estymować bardzo dobrze
jedna osoba za wieloma portfelami	nie można udowodnić, tylko oszacować
„inwestor VC” / prawdziwa osoba	zwykle nie

Ostatnia różnica jest ważna. Bot nie powinien mówić:

„te 7 portfeli należy do Johna Smitha”.

Powinien mówić:

„7 adresów ma 94% prawdopodobieństwa należenia do wspólnego klastra ze względu na wspólne źródło finansowania, timing, zachowanie i wcześniejsze transakcje.”

To jest znacznie bardziej defensywne i użyteczne.

Najważniejsza rzecz: nie analizować tylko DEV-a

To byłby moim zdaniem największy błąd.

Wyobraź sobie profesjonalny zespół, który za każdym razem robi:

MAIN WALLET
      │
      ├── funding → DEV 001 → TOKEN A
      │
      ├── funding → DEV 002 → TOKEN B
      │
      ├── funding → DEV 003 → TOKEN C
      │
      └── funding → DEV 004 → NOWY TOKEN

Sprawdzając wyłącznie DEV 004, zobaczysz świeży portfel bez historii.

Ale bot cofnie się:

DEV 004
  ↓
FUNDER
  ↓
DEV 001
DEV 002
DEV 003

i nagle okaże się:

TOKEN A → peak $4.2M
TOKEN B → peak $16M
TOKEN C → peak $820k

To jest bardzo wartościowy sygnał.

Jeszcze ciekawsza sytuacja:

                    Funder A
                  /    |     \
               W1      W2     W3
               ↓       ↓      ↓
             buy     buy     buy
               \       |      /
                   TOKEN

Jeżeli te same albo powiązane W1/W2/W3 pojawiały się również przy poprzednich winnerach, można zacząć wykrywać całą grupę launchującą tokeny, nawet gdy za każdym razem zmienia deployera.

Właśnie dlatego stworzyłbym „Wallet Reputation”

Każdy wallet dostawałby własną historię.

Przykład:

Wallet: 0xABC...

Role:
EARLY_BUYER

Tokens entered:
47

Successful:
19

Failed:
28

Success rate:
40.4%

Average entry:
23 sec after launch

Median peak after entry:
8.3x

Tokens > $1M:
14

Tokens > $10M:
4

Rugs participated:
3

Average hold time:
8.4h

Associated deployers:
7

Associated wallet cluster:
CLUSTER_018

A dla developera:

Wallet: 0xDEF...

Role:
DEPLOYER

Tokens launched: 12

> $100k: 10
> $1M: 7
> $5M: 3
> $10M: 2

Rugged: 1

Median ATH:
$1.8M

Median lifetime:
11 days

I wtedy nowy token tego walleta automatycznie dostaje bardzo ciekawy sygnał.

Ale możemy pójść jeszcze poziom głębiej

Nie tylko:

„czy ten wallet wcześniej kupił zwycięzcę?”

Bo być może kupił go po +5000%.

Dużo ważniejsze jest:

czy ten wallet potrafił znaleźć zwycięzcę wcześnie?

Czyli dla każdego walleta liczysz:

entry_market_cap
entry_age_seconds
ATH_after_entry
max_return_after_entry
time_to_sell

Przykładowo:

Wallet X

TOKEN A:
entry = $28k
ATH = $3.8M
136x opportunity

TOKEN B:
entry = $41k
ATH = $850k
20x

TOKEN C:
entry = $19k
ATH = $12M
631x

Taki wallet jest potencjalnie smart wallet.

A jeżeli przy nowym tokenie pojawia się:

Smart Wallet X
Smart Wallet Y
Smart Wallet Z

w pierwszych 30 sekundach, to jest dużo ciekawszy sygnał niż samo:

„Top holders wyglądają dobrze”.

I właśnie tutaj Twoje 20 tokenów staje się bardzo wartościowe

Załóżmy, że podajesz botowi 20 tokenów, o których już wiesz, że były sukcesami.

Bot robi intersection analysis.

Na przykład odkrywa:

                   TOKENY
Wallet             A B C D E F G H ...

Wallet 1           ✓ ✓   ✓     ✓
Wallet 2             ✓ ✓ ✓
Wallet 3           ✓     ✓ ✓   ✓
Deployer A         ✓       ✓
Funder X           ✓ ✓ ✓   ✓   ✓

I nagle wychodzi:

Funder X:
powiązany z 9/20 winnerów

Wallet 1:
early buyer w 7/20

Wallet 3:
early buyer w 6/20

Cluster C17:
wystąpił w 13/20

To jest dokładnie zależność, której warto szukać.

Jeszcze ciekawiej będzie, jeśli tych adresów nie ma bezpośrednio w Top Holders.

Mogą kupować:

wallet A1
wallet A2
wallet A3

ale:

A1 ← funding ← MASTER
A2 ← funding ← MASTER
A3 ← funding ← MASTER

Bot powinien sprowadzić je do:

CLUSTER MASTER-17

Graf danych powinien być podstawą systemu

Traktowałbym rzeczy jako nodes:

TOKEN
WALLET
POOL
FACTORY
CONTRACT
CLUSTER

i zależności jako edges:

DEPLOYED
LAUNCHED
FUNDED
BOUGHT
SOLD
TRANSFERRED
HOLDS
CREATED_POOL
PROVIDED_LIQUIDITY
SAME_FUNDER
SAME_CLUSTER

Wtedy np.:

Wallet A
   │
   ├── FUNDED → Wallet B
   │               │
   │               └── DEPLOYED → Token X
   │
   └── FUNDED → Wallet C
                   │
                   └── DEPLOYED → Token Y

zapytanie:

„pokaż tokeny powiązane z Wallet A do 3 hopów”

staje się bardzo proste.

Jak określić „sukces”

To jest absolutnie kluczowa rzecz.

Nie:

success = zrobił 10x

bo scam może zrobić 100x przez 10 sekund.

Dałbym kilka poziomów:

SUCCESS_100K
SUCCESS_500K
SUCCESS_1M
SUCCESS_5M
SUCCESS_10M
SURVIVED_24H
SURVIVED_7D
SURVIVED_30D

oraz:

RUG
DEAD
LOW_LIQUIDITY
DEV_DUMP

Wtedy możesz odkryć coś ciekawszego.

Na przykład:

DEV A

12 tokens launched

10 reached $500k
7 reached $1M
4 reached $5M

BUT

8 collapsed >95% within 24h

To zupełnie inny profil niż:

DEV B

8 tokens

5 reached $1M
4 survived >30 days

Token powinien dostać kilka score’ów, a nie jeden

Nie robiłbym od razu:

TOKEN SCORE = 87

bo tracisz informację.

Lepiej:

DEV REPUTATION       91/100
EARLY BUYERS         86/100
WALLET NETWORK       94/100
DISTRIBUTION         72/100
CONTRACT SAFETY      98/100
LIQUIDITY            61/100
SYBIL RISK           38/100
RUG RISK             21/100

a dopiero z nich:

OPPORTUNITY SCORE = 84
RISK SCORE        = 31

Może więc istnieć coin:

Opportunity: 93
Risk:        78

Czyli potencjalnie bardzo duży ruch, ale ekstremalnie ryzykowna struktura.

To jest bardziej przydatne niż wrzucanie wszystkiego do jednego numeru.

Co powinien robić bot po podaniu 20 adresów

Ja zbudowałbym pipeline mniej więcej taki:

Pobierz contract creation / factory launch.
Zidentyfikuj rzeczywistego deployera.
Znajdź funding deployera.
Cofnij funding graph np. o 2–3 poziomy.
Znajdź wszystkie wcześniejsze tokeny powiązanych deployerów.
Wyciągnij Top 10/20/50 holders.
Wyciągnij pierwszych 20/50/100 kupujących.
Znajdź funderów tych kupujących.
Zbuduj klastry wallets.
Porównaj klastry pomiędzy wszystkimi 20 tokenami.
Policz historyczne wyniki tokenów.
Zbuduj reputację każdego walleta.
Znajdź wspólne cechy zwycięzców.
Zapisz cały graf do własnej bazy.

Robinhood oficjalnie udostępnia RPC i Blockscout; dokumentacja rekomenduje również Alchemy jako dostawcę infrastruktury. (Robinhood)

W przypadku pons sprawa jest jeszcze prostsza: ich dokumentacja podaje TokenLaunched, wraz z token, deployer, pool, initialBuyAmount itd., i wprost zaleca indeksowanie eventów factory oraz pooli jako źródła danych on-chain. (pons)

Co więcej, obecna wersja pons v2 używa już innego stosu kontraktów, więc bot nie powinien mieć jednej zahardcodowanej factory na zawsze — powinien rozpoznawać wersję launchpada dla konkretnego tokena. (pons)

A później robimy Watchera

I to moim zdaniem jest końcowy cel projektu.

Bot słucha każdego nowego launchu.

Przykładowo:

NEW TOKEN DETECTED

0x1234....

Age: 4 sec

DEV:
fresh wallet

BUT:

DEV funded by:
0xABCD...

Funder history:
17 associated launches
8 > $1M MC
3 > $10M MC

Early buyers:
Wallet #17 reputation: 94
Wallet #81 reputation: 89
Wallet #123 reputation: 91

3/20 buyers previously appeared
together on 11 successful launches.

Known cluster:
CLUSTER-07

Cluster historical stats:
34 launches
18 > $500k
9 > $1M
4 > $10M
2 rugs

Top 10:
18.4%

Bundled:
3.2%

Contract:
OK

Liquidity:
OK

────────────────
Opportunity: 91/100
Risk: 27/100

To już byłoby naprawdę interesujące narzędzie.

I może reagować zanim Dexscreener pokaże token, ponieważ dla pons możesz bezpośrednio nasłuchiwać eventu factory; launch tworzy token oraz pool w tej samej transakcji. (pons)

Jedna rzecz, bez której ten projekt łatwo oszuka sam siebie

Musimy bardzo pilnować data leakage.

Załóżmy, że oceniamy token w T+30 sekund.

Model może używać wyłącznie danych, które istniały w:

<= T+30 sekund

Nie wolno przypadkiem wykorzystać:

current holders
current reputation walleta
current market cap
późniejszych transakcji

bo wtedy backtest będzie wyglądał fantastycznie, ale live bot przestanie działać.

Przykład:

Wallet kupił:

Token A w styczniu
Token B w lutym
Token C w marcu
Token D w kwietniu

Gdy analizujemy jego decyzję przy Tokenie B w lutym, jego reputacja może uwzględniać tylko Token A, a nie C i D.

To jest absolutnie krytyczne.

Czy uważam, że to jest dobra metoda szukania coinów?

Tak — ale nie jako „AI przewidujący pump”, tylko jako system wykrywający informacyjną przewagę uczestników rynku.

Hipoteza, którą faktycznie testujesz, brzmi:

„Czy określone adresy, klastry portfeli, deployerzy i źródła finansowania pojawiają się przy zwycięskich tokenach częściej, niż wynikałoby to z przypadku?”

Jeżeli odpowiedź okaże się statystycznie tak, masz coś bardzo wartościowego.

A jeszcze lepsza hipoteza:

„Czy obecność określonego klastra w pierwszych X sekundach/minutach zwiększa prawdopodobieństwo, że token osiągnie określony market cap później?”

To już możemy normalnie zmierzyć.

Przykładowo może wyjść:

bazowe prawdopodobieństwo >$1M:
2.8%

Cluster A present:
11.4%

Cluster A + DEV reputation >80:
21.7%

Cluster A + DEV + low concentration:
34.2%

Wtedy nie działasz na „wydaje mi się”, tylko na danych.

Jak ja bym zaczął

Nie budowałbym na początku AI ani skomplikowanego ML.

Etap 1: Python + Robinhood RPC + Blockscout + PostgreSQL.

Etap 2: podajesz 20–100 znanych winnerów i tyle samo loserów.

Etap 3: automatycznie odtwarzamy deployer → funder → early buyers → top holders → related tokens.

Etap 4: budujemy klastry.

Etap 5: robimy statystykę, które adresy i klastry występują nadmiernie często przy winnerach.

Etap 6: dopiero potem scoring.

Etap 7: live watcher wszystkich nowych launchy.

Na pierwszym etapie nawet Neo4j nie jest konieczny. PostgreSQL + Python networkx spokojnie wystarczą. Jeżeli graf urośnie do milionów powiązań, wtedy można przejść na Neo4j/inna bazę grafową.

Najbardziej interesujące jest to, że Twoje 20 adresów może być naszym pierwszym datasetem treningowym. Jeżeli wybierzemy np. 20 coinów, które uważasz za sukces, oraz 20–50 nieudanych z podobnego okresu, możemy zaprojektować dokładny model danych i sprawdzić, czy już w tej niewielkiej próbce występują wspólne deployery, funderzy, smart wallets albo klastry. To byłby pierwszy test, czy hipoteza rzeczywiście działa na Robinhood Chain.

karol