Programista backend i frontend na Node.js/TypeScript parser tokenów pumpfun lub bonk

1. Logika migracji Dev

• Jeśli adres miał już przynajmniej jeden migrowany token, to wszystkie jego kolejne tokeny:

  • automatycznie otwierają się w przeglądarce (Google Chrome);

  • automatycznie otwierają się w terminalu Axiom.

• Działa dla tokenów z Pump.fun i Bonk.

• Warunek uruchamia się do określonego procentu (próg ustalany przez użytkownika w aplikacji webowej).

• Metryka F – zbierane są dane o tym, ile łącznie prowizji (opłat handlowych) zostało zapłaconych przy tworzeniu tokena.

2. Administrator społeczności

• Każdy token z społecznością ma swojego administratora (na przykład, elonmask).

• Dla pierwszego tokena nowego administratora oprogramowanie zbiera podstawowe metryki.

• Dla kolejnych tokenów dane są uzupełniane i przeliczane.

• Metryki:

  • TT – całkowita liczba stworzonych tokenów przez administratora;

  • ALLAM – mediana maksymalnych marketcap dla wszystkich tokenów;

  • AM – mediana maksymalnych marketcap za ostatnie 5 tokenów;

  • Ostatnie 5 tokenów – przechowywane z klikalnymi nazwami i linkami do Axiom (aby można było zobaczyć każdy token i jego wartość 24K maksymalny cap);

  • F – prowizja zapłacona przez traderów w tokenach.

• Po śmierci tokena jego wartości są rejestrowane i dodawane do obliczeń (aby wyświetlały się na liście ostatnich 5).

3. System banów

• Oprogramowanie zapamiętuje wszystkich administratorów i deweloperów.

• Metryki są liczone nawet dla zbanowanych.

• Przycisk BAN dodaje administratora lub adres dewelopera do czarnej listy (pliku).

• Dwie oddzielne foldery:

  1. Migracja Dev

  2. Administrator społeczności

• Zbanowani nie są wyświetlani w info-tablicy i nie są kupowani, ale dane o nich pozostają w bazie dla statystyki.

4. Sprawdzacz nowych par (Administrator społeczności)

• Śledzi nowe tokeny na Pump.fun i Bonk.

• Sprawdza, czy administrator miał migracje.

• Jeśli token = LAST MIGRATION, to w info-tablicy wyświetlane jest powiadomienie.

• Również następuje automatyczne otwieranie tokena w Axiom (Chrome).

5. Info-tablica: bloki

• MIGRACJA DEV:

  • zdjęcie tokena (nowy),

  • nazwa + ticker,

  • ostatnie 5 tokenów (linki),

  • F (prowizja traderów),

  • % zakupu przez dewelopera,

  • % zakupu przez snajperów.

• ADMINISTRATOR SPOŁECZNOŚCI:

  • zdjęcie tokena (nowy),

  • nazwa + ticker,

  • nick administratora,

  • metryki: ALLAM, AM, TT, ostatnie 5 tokenów i wartości 20K maksymalna marketcap tokenów 5-ciu (linki),

  • F (prowizja traderów),

  • % zakupu przez dewelopera,

  • % zakupu przez snajperów.

• OSTATNIA MIGRACJA SPOŁECZNOŚCI:

  • zdjęcie tokena (nowy),

  • nazwa + ticker,

  • nick administratora,

  • F z poprzedniego migrowanego tokena.

6. Ustawienia (aplikacja webowa → oprogramowanie)

• Ogólne parametry:

  • Próg migracji Dev (%).

  • Limit społeczności (na przykład, 10–12 osób).

  • Auto-otwieranie dla administratora społeczności według wartości marketcap (na przykład, 20K).

  • Próg AM (dla ostatnich 5 tokenów), przy którym włącza się auto-zakup.

  • Przycisk BAN działa we wszystkich kategoriach (Migracja Dev, Administrator społeczności, Ostatnia migracja).

  • Ładowanie i odtwarzanie dźwiękowego powiadomienia, gdy uruchamia się auto-zakup
    
    

• Auto-zakup:

  • portfel do zakupu,

  • kwota zakupu,

  • prowizja (ręczne wprowadzenie),

  • przełączniki:

    • włącz/wyłącz Pump.fun,

    • włącz/wyłącz Bonk,

    • oba włączone → działać na obu,

    • oba wyłączone → nie kupować.

• Aplikacja webowa:

  • 4 oddzielne aplikacje → podłączone do jednej bazy danych;

  • każda może mieć różne portfele/ustawienia;

  • baza administratorów i deweloperów wspólna;

  • bany lokalne (zarządzane ręcznie).

7. Gotowa transakcja przez Jito

• Dla każdej aplikacji webowej jest formułowana z wyprzedzeniem.

• Logika:

  • zbierane są dane o administratorach: TT, ALLAM, AM, ostatnie 5 marketcap, F;

  • jeśli nowy token spełnia określone warunki (na przykład, AM ≥ 20K), to mint jest podstawiany do gotowej transakcji i wysyłany bez opóźnienia.

• Cel: skrócić opóźnienie między pojawieniem się tokena a zakupem, aby maksymalnie trafić w jeden blok z deweloperem.

8. Sprawdzanie wielkości społeczności

• Oprogramowanie sprawdza liczbę osób w społeczności.

• Jeśli limit (na przykład, 10–12) jest przekroczony, to:

  • nie otwierać,

  • nie kupować, nawet przy dobrych metrykach AM.

9. Tryby pracy

• Tryb AFK (w tle):

  • sprawdzenie nowych par tylko przez Administratora społeczności,

  • zbieranie danych: ALLAM, AM, TT, ostatnie 3 tokeny,

  • bez auto-zakupu i auto-otwierania,

  • działa cały czas.

• Tryb START (bojowy):

  • włącza się ręcznie,

  • pełna funkcjonalność (auto-otwieranie, auto-zakup itd.),

  • używa zebranej bazy.

• Zarządzanie:

  • przycisk uruchamiania/zatrzymywania trybu AFK,

  • przycisk uruchamiania/zatrzymywania trybu START.

10. Dodatkowe foldery (Dashboard)

• Folder nr 1: nick administratora (na przykład, elonmask) + podpis (na przykład, TOP ADMIN / HOLD).

• Folder nr 2: portfel dewelopera migracji (na przykład, 3bHqLAMq...pump) + podpis (na przykład, TOP DEV / HOLD).

• Dla tych folderów działa auto-zakup niezależnie od metryk (za każdym razem, gdy wskazany administrator/deweloper tworzy nowy token).
  
  Mam już część kodu backendu, jest on załadowany na mój GitHub, mogę również szczegółowo wyjaśnić i pokazać wideo przykład, jak działa podobny projekt, aby pełniej zrozumieć, jak to powinno być zrealizowane.