Zum Inhalt springen
J Tools öffnen

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-kurzfassung

Nicht-verwahrend von Grund auf

#nicht-verwahrend-von-grund-auf

J 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-protokoll

Admin-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-limits

Der 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-gebuhrendiebstahl

Berechnet 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-abgesichert

Fü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.

OPSEC überall

#opsec-uberall

Operative 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.