Six pillars.
Zero trust in chat.
Every Solana memecoin bot is one master-key leak away from disaster. Here is exactly how MoonHydra defends yours — and where the limits are.
AES-256-GCM at rest
Every Hydra Head private key is encrypted with AES-256-GCM before being saved to PostgreSQL. The master key lives only in the operator's environment — never in the repo, never in chat, never in logs. Each wallet has its own random IV; tampering invalidates the auth tag and decryption fails loudly.
Logs are redacted
Pino logger has explicit field-level redactors for encryptedKey, iv, authTag, secretKey, privateKey, and MASTER_ENCRYPTION_KEY. Even if a developer accidentally logs a wallet object, the secret fields are stripped with [REDACTED].
No key export, no seed phrases
Hydra Heads are generated server-side. We never send a private key over Telegram, never email it, never echo it back. To exit, use /withdraw — the bot signs a SOL transfer to any address you specify. No seed phrases are derived; the random keypair is the source of truth.
Burner wallets only
MoonHydra deliberately does NOT support importing existing wallets in Phase 1. Importing private keys via Telegram is a phishing-bait vector — we refuse the pattern entirely. Phase 2 may add a guarded import flow with multi-step confirmation, but it's opt-in.
Operator-controlled infrastructure
MoonHydra runs on a single operator-managed stack — Railway for the bot, Postgres + Redis for state, Helius for Solana RPC. Every database query, every swap, every key decryption happens inside this perimeter. No third-party plugins. No untrusted middlemen between you and Jupiter.
No custody, no pooling
Each user has their own Hydra Heads. There is no shared treasury, no pooled wallet, no operator-controlled vault. The only signer for your trades is your encrypted keypair, decrypted into RAM only when a swap is actually executing.
Threat model
Honest about what MoonHydra defends against — and what it can't.
⚠️ Operator server compromise
Attacker needs the database AND the master encryption key. Master key lives in Railway env vars, not in DB or repo. Even with full DB dump, wallets are unreadable without the key.
⚠️ Stolen Telegram account
Whoever controls your Telegram session controls your Hydra Heads. Enable Telegram 2FA. Use cloud-password protection. Treat Telegram security as wallet security.
⚠️ Rug-pull / honeypot token
Phase 3 ships Rugcheck integration that scores tokens before buy. For now: never YOLO a token you haven't verified on Solscan + Dexscreener.
⚠️ Sandwich / MEV attack
Phase 3 routes all trades through Jito Block Engine bundles with a configurable tip. Bundled txs cannot be front-run by searchers.
⚠️ Master key loss
IRRECOVERABLE. If the operator loses MASTER_ENCRYPTION_KEY, every Hydra Head's funds become permanently inaccessible. Mitigation: redundant secure backups of the key by the operator. Users should keep most funds OUT of Hydra Heads — only fund what you're actively trading.
⚠️ Telegram bot impersonation
The only legitimate bot is @moonhydrabot. Always verify the handle. Telegram's bot username system prevents collisions, but phishing channels with similar names exist. Bookmark t.me/moonhydrabot.
Built on standard primitives
MoonHydra's encryption is plain Node.js crypto.createCipheriv('aes-256-gcm', …) — no custom cryptography, no third-party dependencies in the security-critical path. AES-256-GCM is an industry-standard authenticated encryption scheme; its security has been studied and battle-tested for over a decade.
Internal round-trip tests verify the contract: encrypt → decrypt = identity, tampered ciphertext fails, tampered auth tag fails. Every release runs them automatically before deploy. Any deviation breaks the build.
Stay paranoid. Trade anyway.
Security is a process, not a feature. Use burners, withdraw profits, enable Telegram 2FA, never trust a bot with funds you can't afford to lose.
Open in Telegram