Nasz model bezpieczeństwa

J Tools wykonuje operacje na twoich tokenach, nigdy nie przejmując kontroli nad twoim portfelem. Transakcje z twoich portfeli są podpisywane po twojej stronie, platforma je buduje i wysyła, a za tym wszystkim stoją zabezpieczenia po stronie serwera.

W skrócie

#w-skrocie

Wskazówka

Klucze połączonego portfela zostają w tym portfelu, przeglądarce nigdy nie powierzamy ustalania kwoty opłaty, a sekrety nie trafiają do logów. Dostęp administratora wymaga drugiego składnika, a ślad audytowy jest zbudowany tak, że każda ingerencja wychodzi na jaw.

Bez powierzania środków z założenia

#bez-powierzania-srodkow-z-załozenia

J Tools nigdy nie prosi o frazę seed i nigdy nie przechowuje twoich środków. Gdy korzystasz z połączonego portfela, każdy podpis powstaje w tym portfelu przez adapter portfela, a do sieci trafia tylko podpisana transakcja. Klucz prywatny portfela nigdy go nie opuszcza.

Strona J Tools

1Konfigurujesz operację w J Tools

Transakcja trafia do twojego portfela

Twój portfel

2Portfel pokazuje transakcję

3Zatwierdzasz i podpisujesz we własnym portfelu

Klucze podłączonego portfela nigdy go nie opuszczają

Wychodzi tylko podpis, nigdy klucz

Solana

4Podpisana transakcja trafia do sieci Solana

Niektóre narzędzia mogą też podpisywać kluczami prywatnymi, które wklejasz, bo działają na wielu portfelach, których żaden adapter nie połączy. Należą do nich między innymi Handel w pakiecie, Multi Swap, Multi Sender, Zbieranie sald, narzędzia relay, Utwórz i kup w pakiecie na Pump.fun oraz narzędzia do odbioru opłat. Te klucze zostają w karcie przeglądarki i tam podpisują, nie są do nas wysyłane. Klucz wklejony jako źródło klucza prywatnego narzędzia jest czyszczony po 15 minutach. Traktuj takie portfele jako jednorazowe hot wallety. Holder Booster to jedyne narzędzie, które przekazuje klucz naszym serwerom: przy każdym uruchomieniu tworzy nowy portfel dystrybutora, klucze portfeli posiadaczy zapisuje w pobieranym przez ciebie pliku kopii zapasowej i wysyła tylko klucz dystrybutora, zaszyfrowany, aby nasz worker mógł dokończyć zadanie po zamknięciu karty. Jeśli jakaś strona prosi o twoją frazę odzyskiwania, to nie my.

Łańcuch audytowy odporny na manipulacje

#łancuch-audytowy-odporny-na-manipulacje

Działania administratora są zapisywane w dzienniku audytowym, do którego można tylko dopisywać. Każdy wiersz ma prev_hash, czyli skrót SHA-256 poprzedniego wiersza, więc wpisy łączą się jak ogniwa łańcucha. Zmień lub usuń jeden wiersz, a każdy kolejny skrót przestanie się zgadzać, co od razu ujawnia edycję. Wpisy w dzienniku nie zawierają haseł ani tokenów sesji.

Biała lista RPC i limity zapytań

#biała-lista-rpc-i-limity-zapytan

Przeglądarka nie łączy się bezpośrednio z węzłem Solana. Przechodzi przez bramę, która dopuszcza tylko stałą listę metod odczytu oraz wysyłanie i symulację transakcji, a liczbę zapytań ogranicza na adres IP. Adresy URL i klucze RPC zostają po stronie serwera, więc przeglądarka nie ma czego ujawnić. Limity obowiązują dla każdego endpointu osobno, a prawdziwy adres IP klienta jest odczytywany z ostatniej od prawej wartości x-forwarded-for, więc limitu nie da się obejść podrobionym nagłówkiem.

Ochrona przed kradzieżą opłat

#ochrona-przed-kradzieza-opłat

Gdy narzędzie pobiera opłatę platformy, kwota zapisywana na potrzeby prowizji pochodzi z naszych ustawień opłat albo z SOL, które faktycznie dotarły on-chain do portfela platformy, nigdy z liczby wysłanej przez przeglądarkę. Żadna ścieżka nie ufa opłacie podanej przez klienta. Pełne rozbicie kosztów (suma, opłata platformy i szacowana opłata sieciowa) widzisz na karcie opłat narzędzia, zanim cokolwiek potwierdzisz. Wartości referencyjne znajdziesz w podsumowaniu opłat w aplikacji albo na stronie Cennik opłat.

Uwaga

Opłaty. Każda operacja ma dwa koszty: opłatę sieciową Solana, którą dostają walidatorzy, i opłatę platformy J Tools. Opłata platformy zawsze jest widoczna w aplikacji, zanim potwierdzisz, i nic nie zostaje pobrane, dopóki nie podpiszesz. Opłaty mogą się z czasem zmieniać, więc kieruj się podsumowaniem w aplikacji, a nie kwotą widzianą kiedyś wcześniej.

Zamknięty dostęp administratora

#zamkniety-dostep-administratora

Wejście do panelu administratora wymaga hasła i kodu TOTP, a serwer to egzekwuje. Cały proces jest zbudowany tak, aby niczego nie zdradzać.

Drugi składnik Przechowywanie haseł Brak wycieku informacji Sesje

TOTP jest obowiązkowy. Kody są sprawdzane po stronie serwera, a seria nieudanych prób blokuje logowanie na pewien czas. Powód blokady nigdy nie jest odsyłany do klienta.

Hasła administratorów są przechowywane wyłącznie jako jednokierunkowe skróty, ustawiane przez zmienne środowiskowe. Ani panel, ani API nie mają ekranu resetu hasła; zmiana oznacza nową wartość zmiennej i nowe wdrożenie.

Nieudane logowanie zwraca ten sam ogólny komunikat bez względu na to, czy błędna jest nazwa użytkownika, hasło czy kod, a sprawdzenie nieznanej nazwy użytkownika trwa tyle samo co prawdziwej. Zablokowane logowanie mówi tylko, że prób było za dużo, nigdy który limit zadziałał. Próby logowania są ograniczane zarówno według IP, jak i nazwy użytkownika.

Sesje są przechowywane po stronie serwera, z ciasteczkami httpOnly, Secure, SameSite=Strict i losowymi identyfikatorami. Przy logowaniu są odnawiane, co chroni przed atakiem typu session fixation, wygasają po okresie bezczynności, a ich liczba na administratora jest ograniczona.

OPSEC wszędzie

#opsec-wszedzie

Bezpieczeństwo operacyjne to stała zasada dla każdego endpointu i każdej strony. Sekrety, klucze prywatne i pełne tokeny nie trafiają do logów. Odpowiedź z błędem dla klienta zawiera krótki komunikat, często z kodem, bez śladu stosu, wewnętrznej ścieżki czy szczegółów bazy danych; pełny obraz zostaje w logach serwera. Wpisy na blogu przygotowane przez automatyzację pozostają szkicami, dopóki administrator ich nie opublikuje, więc nic nie dociera do czytelników bez zgody człowieka.