Ons beveiligingsmodel

J Tools voert je tokenhandelingen uit zonder ooit je wallet in bewaring te nemen. Transacties vanuit je wallets worden aan jouw kant ondertekend, het platform bouwt en verstuurt ze, en daarachter zitten beveiligingen op de server.

De korte versie

#de-korte-versie

Tip

De sleutels van een verbonden wallet blijven in die wallet, de browser mag nooit een kostenbedrag bepalen en geheimen blijven uit de logs. Beheerderstoegang zit achter een tweede factor, en het auditspoor is zo gebouwd dat elke manipulatie zichtbaar wordt.

Non-custodial door ontwerp

#non-custodial-door-ontwerp

J Tools vraagt nooit om je herstelzin en houdt nooit je geld. Gebruik je een verbonden wallet, dan gebeurt elke ondertekening in die wallet via de wallet-adapter, en alleen de ondertekende transactie gaat naar het netwerk. De privésleutel van de wallet verlaat die nooit.

J Tools-pagina

1Je stelt een actie in J Tools in

De transactie komt naar je wallet

Je wallet

2Je wallet toont de transactie

3Je keurt de transactie goed en ondertekent in je eigen wallet

A connected wallet's keys never leave it

Alleen de handtekening verlaat de wallet, nooit de sleutel

Solana

4De ondertekende transactie wordt uitgezonden naar Solana

Sommige tools kunnen ook ondertekenen met privésleutels die je plakt, omdat ze werken met veel wallets die geen adapter verbindt: onder meer Gebundelde handel, Multi Swap, Multi Sender, Batchverzamelaar, de relay-tools, Pump.fun Maken & Bundle Kopen en de claimtools. Die sleutels blijven in je browsertabblad, ondertekenen daar en worden niet naar ons gestuurd. Een sleutel die als privésleutelbron van een tool is geplakt, wordt na 15 minuten gewist. Behandel dit als wegwerp-hot-wallets. Houderbooster is de enige tool die onze servers een sleutel geeft: die maakt per run een nieuwe distributeurwallet, bewaart de sleutels van de houderwallets in het back-upbestand dat je downloadt en stuurt alleen de sleutel van de distributeur, versleuteld, zodat onze worker de run kan afmaken nadat je het tabblad sluit. Vraagt een pagina om je herstelzin, dan zijn wij dat niet.

Een fraudebestendige auditketen

#een-fraudebestendige-auditketen

Beheerdersacties worden in een auditlog geschreven waar alleen aan kan worden toegevoegd. Elke regel bevat een prev_hash, een SHA-256-hash van de regel ervoor, zodat de items als een ketting aan elkaar hangen. Wijzig of verwijder één regel en elke hash daarna klopt niet meer, waardoor de bewerking meteen opvalt. Logitems laten wachtwoorden en sessietokens weg.

Toegestane RPC-methoden en verzoeklimieten

#toegestane-rpc-methoden-en-verzoeklimieten

De browser praat niet met een kale Solana-node. Hij gaat via een gateway die alleen een vaste lijst leesmethoden plus het verzenden en simuleren van transacties toestaat, en die het aantal verzoeken per IP begrenst. RPC-URL’s en sleutels blijven op de server, dus de browser heeft niets om te lekken. Verzoeklimieten gelden per endpoint, en het echte IP van de client wordt gelezen uit de meest rechtse x-forwarded-for-waarde, zodat de limiet niet met een vervalste header te omzeilen is.

Bescherming tegen kostendiefstal

#bescherming-tegen-kostendiefstal

Rekent een tool platformkosten, dan komt het bedrag dat voor commissie wordt geregistreerd uit onze eigen kosteninstellingen of uit de SOL die on-chain echt in de platformwallet is aangekomen, nooit uit een getal dat de browser stuurt. Geen enkele route vertrouwt kosten die de client aanlevert. Je ziet de volledige uitsplitsing (totaal, platformkosten en geschatte netwerkkosten) op de kostenkaart van de tool voordat je iets bevestigt. Voor de referentiebedragen bekijk je het kostenoverzicht in de app of het tariefschema.

Opgepast

Over vergoedingen. Bij een betaalde on-chain actie zijn er verschillende kosten: de Solana netwerkkosten voor validators en de J Tools-platformkosten. Daarnaast kan rent voor nieuwe accounts nodig zijn. De app toont de kosten vóór bevestiging. Er wordt geen transactie uitgevoerd zonder de daarvoor benodigde ondertekening. Tarieven kunnen veranderen; controleer altijd het actuele overzicht.

Beheerderstoegang is vergrendeld

#beheerderstoegang-is-vergrendeld

Voor het beheerderspaneel zijn een wachtwoord en een TOTP-code nodig, afgedwongen op de server. Het proces is zo gebouwd dat het niets prijsgeeft.

Tweede factor Wachtwoordopslag Geen informatielek Sessies

TOTP is verplicht. Codes worden aan de serverzijde gecontroleerd en een reeks mislukte pogingen vergrendelt de aanmelding voor een afkoelperiode. De vergrendelingsreden wordt nooit teruggestuurd naar de klant.

Beheerderswachtwoorden worden alleen als eenrichtingshash opgeslagen, ingesteld via omgevingsvariabelen. Er is geen scherm om een wachtwoord te resetten in het paneel of de API; een wijziging betekent een nieuwe env-waarde en een deploy.

Een mislukte aanmelding geeft dezelfde algemene melding, of nu de gebruikersnaam, het wachtwoord of de code fout is, en een onbekende gebruikersnaam kost evenveel tijd om te controleren als een echte. Een vergrendelde aanmelding zegt alleen dat er te veel pogingen waren, nooit welke limiet werd geraakt. Aanmeldpogingen zijn begrensd per IP en per gebruikersnaam.

Sessies staan in een opslag op de server met httpOnly-, Secure- en SameSite=Strict-cookies en willekeurige ID’s. Ze wisselen bij het aanmelden om fixatie tegen te gaan, verlopen bij inactiviteit en zijn per beheerder begrensd.

OPSEC overal

#opsec-overal

Operationele beveiliging is een vaste regel voor elk endpoint en elke pagina. Geheimen, privésleutels en volledige tokens blijven uit de logs. Een foutantwoord aan de client bevat een kort bericht, vaak met een code, en geen stacktrace, intern pad of databasedetail; het volledige beeld blijft in de serverlogs. Blogberichten die automatisch zijn opgesteld, blijven concepten tot een beheerder ze publiceert, dus niets bereikt lezers zonder dat een mens het goedkeurt.