Sicurezza Botely in sintesi
Riepilogo in linguaggio piano di cosa Botely vede, cosa non vede, e come il modello permissioned-key on-chain limita il blast radius in caso di compromissione.
Cosa Botely vede
La tua email di account + il tuo owner address dydx1… (pubblico).
Copia cifrata at-rest della tua trading-key private key (AES-256-GCM con master key server-side). È per readiness Phase 1 — in Phase 0 il bot legge la key dal suo host .env, non da questa riga DB.
Storia dei trade dei signal che ti sono stati consegnati. Parametri di strategia (pubblici). Stato del toggle bot.
Cosa Botely NON vede MAI
La tua wallet mnemonic / recovery phrase. Keplr o Ledger la tengono. Non è mai inviata a Botely sotto nessuna circostanza.
La tua trading-key private key in chiaro dopo la POST iniziale di register. Il server la cifra immediatamente e conserva solo il ciphertext.
I dettagli della tua carta di pagamento Stripe. Stripe gestisce i pagamenti; Botely riceve solo un customer ID.
Blast radius se trapelano varie cose
Trading key trapela: l'attaccante può place/cancel ordini su ETH/SOL/BNB sub 0. Non può trasferire né withdraw. Tu revochi + ruoti (~$0.50 gas) e torni clean. Vedi trading-key-security-model per i dettagli completi della whitelist.
Server Botely compromesso: l'attaccante ottiene blob trading-key cifrati ma non può decifrarli senza la master key server-side (che vive in un env var separato su tier di hardening separato). Anche decifrate, vedi punto sopra — le key sono pesantemente scoped.
Trapela la tua mnemonic: catastrofico — vedi il runbook wallet-compromise. La chain non ha modo di rollbackare; l'attaccante può muovere fondi. Non conservare la mnemonic su nessun device internet-connected oltre il secure element di un hardware wallet.
Trasparenza del codice
Il bot di trading + SaaS sono entrambi nello stesso repo. Tutto ciò descritto in queste guide può essere verificato leggendo il codice.
La pagina /security elenca gli audit esterni e la storia di code-review.