Il nostro modello di sicurezza

J Tools esegue le tue operazioni sui token senza mai prendere in custodia il tuo wallet. Le transazioni dei tuoi wallet vengono firmate dalla tua parte, la piattaforma le costruisce e le invia, e dietro a tutto ci sono controlli lato server.

In breve

#in-breve

Consiglio

Le chiavi di un wallet collegato restano dentro quel wallet, al browser non viene mai affidato l’importo di una commissione e i segreti restano fuori dai log. L’accesso admin richiede un secondo fattore, e il registro di audit è costruito in modo che qualsiasi manomissione si veda.

Non-custodial per progettazione

#non-custodial-per-progettazione

J Tools non chiede mai la tua seed phrase e non custodisce mai i tuoi fondi. Quando usi un wallet collegato, ogni firma avviene dentro quel wallet tramite il wallet adapter, e alla rete arriva solo la transazione firmata. La chiave privata del wallet non esce mai da lì.

Pagina J Tools

1Prepari un'azione in J Tools

La transazione arriva nel tuo wallet

Il tuo wallet

2Il tuo wallet mostra la transazione

3Approvi e firmi nel tuo wallet

Le chiavi di un wallet collegato non ne escono mai

Esce solo la firma, mai la chiave

Solana

4La transazione firmata viene trasmessa a Solana

Alcuni strumenti possono firmare anche con chiavi private che incolli, perché lavorano su molti wallet che nessun adapter collega: tra questi Trade in bundle, Multi swap, Invio multiplo, Raccolta in batch, gli strumenti di relay, Pump.fun: crea e compra in bundle e gli strumenti di riscossione. Quelle chiavi restano nella scheda del browser, firmano lì e non vengono inviate a noi. Una chiave incollata come fonte di chiave privata di uno strumento viene cancellata dopo 15 minuti. Considerali hot wallet usa e getta. Holder Booster è l’unico strumento che dà una chiave ai nostri server: crea un wallet distributore nuovo per ogni esecuzione, tiene le chiavi dei wallet holder nel file di backup che scarichi e invia solo la chiave del distributore, cifrata, così il nostro worker può completare l’esecuzione anche dopo che hai chiuso la scheda. Se una pagina ti chiede la frase di recupero, non siamo noi.

Un registro di audit a prova di manomissione

#un-registro-di-audit-a-prova-di-manomissione

Le azioni degli amministratori vengono scritte in un log di audit in sola aggiunta. Ogni riga contiene un prev_hash, cioè un hash SHA-256 della riga precedente, quindi le voci sono legate come una catena. Se si modifica o si cancella una riga, tutti gli hash successivi smettono di corrispondere e la modifica diventa evidente. Le voci del log non contengono password né token di sessione.

Whitelist RPC e limiti di richieste

#whitelist-rpc-e-limiti-di-richieste

Il browser non parla direttamente con un nodo Solana. Passa da un gateway che consente solo un elenco fisso di metodi di lettura più l’invio e la simulazione delle transazioni, e limita le richieste per IP. URL e chiavi RPC restano sul server, quindi il browser non ha nulla da esporre. I limiti di richieste valgono per endpoint, e l’IP reale del client viene letto dal valore più a destra di x-forwarded-for, così il limite non si può aggirare con un header falsificato.

Protezione contro il furto delle commissioni

#protezione-contro-il-furto-delle-commissioni

Quando uno strumento addebita una commissione di piattaforma, l’importo registrato per le provvigioni viene dalle nostre impostazioni delle commissioni o dai SOL arrivati davvero on-chain al wallet della piattaforma, mai da un numero inviato dal browser. Nessun percorso si fida di una commissione fornita dal client. Prima di confermare qualsiasi cosa vedi il dettaglio completo (totale, commissione di piattaforma e commissione di rete stimata) nel riquadro delle commissioni dello strumento. Per i valori di riferimento, guarda il riepilogo delle commissioni nell’app o la tabella delle tariffe.

Attenzione

Sulle commissioni. Ogni azione ha due costi: la commissione di rete di Solana, pagata ai validator, e la commissione di piattaforma di J Tools. La commissione di piattaforma compare sempre nell’app prima della conferma, e non paghi nulla finché non firmi. Le commissioni possono cambiare nel tempo, quindi fidati del riepilogo nell’app e non di una cifra vista una volta.

L’accesso admin è blindato

#laccesso-admin-e-blindato

Per entrare nel pannello admin servono una password e un codice TOTP, verificati sul server. Il flusso è costruito per non rivelare nulla.

Secondo fattore Conservazione delle password Nessuna fuga di informazioni Sessioni

Il TOTP è obbligatorio. I codici vengono verificati lato server, e una serie di tentativi falliti blocca l’accesso per un periodo di attesa. Il motivo del blocco non viene mai inviato al client.

Le password admin sono salvate solo come hash non reversibili, configurati tramite variabili d’ambiente. Nel pannello e nell’API non c’è nessuna schermata di reset della password; per cambiarla servono un nuovo valore nelle variabili d’ambiente e un nuovo deploy.

Un accesso fallito restituisce lo stesso messaggio generico sia che siano sbagliati il nome utente, la password o il codice, e un nome utente inesistente richiede lo stesso tempo di verifica di uno reale. Un accesso bloccato dice solo che ci sono stati troppi tentativi, mai quale limite è scattato. I tentativi di accesso sono limitati sia per IP sia per nome utente.

Le sessioni sono salvate sul server, con cookie httpOnly, Secure, SameSite=Strict e ID casuali. Vengono rigenerate a ogni accesso per difendersi dagli attacchi di session fixation, scadono dopo un periodo di inattività e hanno un numero massimo per amministratore.

OPSEC ovunque

#opsec-ovunque

La sicurezza operativa è una regola fissa su ogni endpoint e ogni pagina. Segreti, chiavi private e token completi restano fuori dai log. Una risposta di errore al client contiene un breve messaggio, spesso con un codice, e nessuno stack trace, percorso interno o dettaglio del database; il quadro completo resta nei log del server. Gli articoli del blog scritti in automatico restano bozze finché un amministratore non li pubblica, quindi niente arriva ai lettori senza l’approvazione di una persona.