Unser Sicherheitsmodell
J Tools führt deine Token-Operationen aus, ohne jemals die Verwahrung deiner Wallet zu übernehmen. Transaktionen aus deinen Wallets werden auf deiner Seite signiert, die Plattform baut und sendet sie, und hinter allem stehen Schutzmechanismen auf dem Server.
Die Kurzfassung
#die-kurzfassungNicht-verwahrend von Grund auf
#nicht-verwahrend-von-grund-aufJ Tools fragt nie nach deiner Seed-Phrase und hält nie dein Guthaben. Nutzt du eine verbundene Wallet, passiert jede Signatur in dieser Wallet über den Wallet-Adapter, und nur die signierte Transaktion geht ins Netzwerk. Der Private Key der Wallet verlässt sie nie.
J Tools-Seite
1Du bereitest eine Aktion in J Tools vor
Die Transaktion kommt in deine Wallet
Deine Wallet
2Deine Wallet zeigt die Transaktion an
3Du bestätigst und signierst in deiner eigenen Wallet
Die Schlüssel einer verbundenen Wallet verlassen sie nie
Nur die Signatur geht hinaus, nie der Schlüssel
Solana
4Die signierte Transaktion wird an Solana gesendet
Einige Tools können außerdem mit Private Keys signieren, die du einfügst, weil sie über viele Wallets hinweg arbeiten, die kein Adapter verbindet: darunter Bundle-Handel, Multi-Swap, Multisender, Guthaben einsammeln, die Relay-Tools, Pump.fun erstellen & Bundle-Kauf und die Claim-Tools. Diese Schlüssel bleiben in deinem Browser-Tab und signieren dort, an uns werden sie nicht gesendet. Ein Schlüssel, den du als Schlüsselquelle eines Tools einfügst, wird nach 15 Minuten gelöscht. Behandle solche Wallets als Wegwerf-Hot-Wallets. Holder Booster ist das einzige Tool, das unseren Servern einen Schlüssel gibt: Es erstellt für jeden Durchlauf eine frische Verteiler-Wallet, legt die Schlüssel der Inhaber-Wallets in die Sicherungsdatei, die du herunterlädst, und sendet nur den Schlüssel der Verteiler-Wallet, verschlüsselt, damit unser Worker den Durchlauf beenden kann, nachdem du den Tab geschlossen hast. Fragt eine Seite nach deiner Seed-Phrase, kommt das nicht von uns.
Ein manipulationssicheres Audit-Protokoll
#ein-manipulationssicheres-audit-protokollAdmin-Aktionen werden in ein Audit-Log geschrieben, an das nur angehängt wird. Jede Zeile trägt einen prev_hash, einen SHA-256-Hash der Zeile davor, die Einträge sind also wie eine Kette verknüpft. Ändert oder löscht jemand eine Zeile, passt kein Hash danach mehr, und die Änderung fällt sofort auf. Passwörter und Sitzungs-Tokens landen nicht in den Log-Einträgen.
RPC-Freigabeliste und Rate-Limits
#rpc-freigabeliste-und-rate-limitsDer Browser spricht nicht direkt mit einem Solana-Node. Er geht über ein Gateway, das nur eine feste Liste von Lesemethoden sowie das Senden und Simulieren von Transaktionen zulässt und die Anfragen pro IP begrenzt. RPC-URLs und Schlüssel bleiben auf dem Server, im Browser gibt es also nichts, was nach außen dringen könnte. Rate-Limits gelten pro Endpunkt, und die echte Client-IP wird aus dem letzten Wert von x-forwarded-for gelesen, damit sich das Limit nicht mit einem gefälschten Header umgehen lässt.
Schutz vor Gebührendiebstahl
#schutz-vor-gebuhrendiebstahlBerechnet ein Tool eine Plattformgebühr, stammt der Betrag, der für Provisionen erfasst wird, aus unseren eigenen Gebühreneinstellungen oder aus dem SOL, das on-chain tatsächlich in der Plattform-Wallet angekommen ist, nie aus einer Zahl, die der Browser schickt. Kein Weg vertraut einer Gebühr, die der Client liefert. Die vollständige Aufschlüsselung (Gesamtbetrag, Plattformgebühr und geschätzte Netzwerkgebühr) siehst du auf der Gebührenkarte des Tools, bevor du etwas bestätigst. Die Richtwerte findest du in der Gebührenzusammenfassung der App oder in der Gebührenübersicht.
Der Admin-Zugang ist abgesichert
#der-admin-zugang-ist-abgesichertFür den Zugang zum Admin-Panel braucht es ein Passwort und einen TOTP-Code, geprüft auf dem Server. Der Ablauf ist so gebaut, dass er nichts verrät.
TOTP ist Pflicht. Codes werden auf dem Server geprüft, und eine Reihe fehlgeschlagener Versuche sperrt die Anmeldung für eine Wartezeit. Der Grund der Sperre wird nie an den Client zurückgeschickt.
Admin-Passwörter werden nur als Einweg-Hashes gespeichert und über Umgebungsvariablen konfiguriert. Im Panel und in der API gibt es keine Funktion zum Zurücksetzen des Passworts; eine Änderung heißt neuer Wert in der Umgebungsvariable und neues Deployment.
Eine fehlgeschlagene Anmeldung liefert dieselbe allgemeine Meldung, egal ob Benutzername, Passwort oder Code falsch sind, und ein unbekannter Benutzername braucht für die Prüfung genauso lange wie ein echter. Eine gesperrte Anmeldung sagt nur, dass es zu viele Versuche gab, nie welches Limit gegriffen hat. Anmeldeversuche werden sowohl pro IP als auch pro Benutzername begrenzt.
Sitzungen liegen in einem Speicher auf dem Server, mit Cookies, die httpOnly, Secure und SameSite=Strict gesetzt haben, und zufälligen IDs. Sie werden bei der Anmeldung erneuert, um Session Fixation abzuwehren, laufen bei Inaktivität ab und sind pro Admin begrenzt.
OPSEC überall
#opsec-uberallOperative Sicherheit ist eine feste Regel für jeden Endpunkt und jede Seite. Geheimnisse, Private Keys und vollständige Tokens werden aus den Logs herausgehalten. Eine Fehlerantwort an den Client enthält eine kurze Meldung, oft mit einem Code, aber keinen Stacktrace, keinen internen Pfad und keine Datenbankdetails; das ganze Bild bleibt in den Server-Logs. Blogartikel, die automatisch entworfen werden, bleiben Entwürfe, bis ein Admin sie veröffentlicht. So erreicht nichts die Leser, ohne dass ein Mensch es freigegeben hat.
© 2026 J Tools