Solana Trading Bot Security Checklist

Funding a Solana trading bot is funding a piece of software you didn't write to sign transactions on your behalf. The promise is automation; the risk is that the bot, the operator, or any link in their chain becomes a single point of failure. This checklist is what to verify before you send the first SOL — eight concrete questions you can answer in five minutes that filter out most of the bots that should not be trusted with anyone's money.

1. What's the custody model — really?

Every bot calls itself non-custodial. A few mean it. The honest spectrum: pooled hot wallet (worst — single operator key drains every user), operator-encrypted dedicated wallet (pragmatic for auto-trade if encryption is honest), user-encrypted dedicated wallet (better cryptographically but usually has UX-collapsed runtime caching), signing-relay to your real wallet (gold standard, unworkable for automation). Read the operator's own description of which model they use; if they cannot or will not answer in one paragraph, assume the worst. For the full breakdown see our custody deep-dive.

2. Can you export your private key off-platform?

If the bot doesn't offer key export, you don't actually control the wallet. The "your funds, your wallet" claim is meaningless when there's no migration path off the platform. Verify that the bot supports exporting the keypair in a format you can import into Phantom, Solflare, or a Solana CLI keypair JSON. If the answer is "contact support" or "the wallet is locked to our platform", you're looking at functional custody dressed up as something else.

3. How does the bot handle keys in logs and errors?

Decrypted private keys touch RAM during every swap. They should never touch logs, never get echoed back to users, never appear in admin error notifications. Operators that take this seriously have explicit field-level log redactors (look for names like Pino redactors), refuse to print keys to admin DMs, and auto-delete incoming wallet-import messages from chat history. The casual tell is a public commitment in the bot's docs to never log decrypted keys; the rigorous tell is the redaction config in the source.

4. What gates the withdraw flow?

Withdrawing SOL out of the bot wallet is the single most consequential action. The protection should match. Look for: optional withdrawal password (scrypt-hashed in the DB), optional TOTP 2FA (Google Authenticator / Authy / 1Password compatible), brute-force lockout (typically 5 wrong attempts → 15 minute cooldown), TOCTOU protection on the destination address (frozen at confirm time, not re-read later). A bot that lets you withdraw with just one tap is a bot that a Telegram session hijack drains in thirty seconds.

5. Does it gate trades with a rug score?

Most rugs and honeypots are knowable up-front via public risk-scoring APIs (RugCheck is the dominant one on Solana). A bot that fetches the score, surfaces it on the token card, and lets you set a hard block when the score exceeds your threshold is a bot that prevents a class of mistakes you would otherwise make at 3am. The threshold should be user-configurable (Strict / Default / Loose / Disabled) because risk tolerance is personal. API failures should fail open (don't lock users out of legitimate trades during a third-party outage), but the gate itself is a basic table-stakes feature in 2026.

6. How is the operator's code shipped?

The operator can change the bot's behavior at any time. The question is whether that change process leaves a public trail. Look for: a public changelog with dated entries (not "v1.2 — bug fixes"), a visible commit history, public PRs, an operator who responds to security@ emails. The opposite — opaque "we improved performance" blog posts, no version numbers, no incident retrospectives — is a pattern that lets the operator quietly add features that would have been flagged in public.

7. Does the product nudge you toward burner discipline?

A trading bot wallet is not a treasury wallet. Operators that understand this push burner discipline into the onboarding flow: fund with risk capital only, withdraw profits out, expect the wallet to be at-risk at all times. Operators that treat their bot wallet like a savings account are signaling a different mental model — one where "we'll be careful" is supposed to substitute for "you compartmentalize". The marketing copy gives away which mental model the operator actually has.

8. What's the social-engineering posture?

Every successful bot drain in the last two years involved some flavor of social engineering — fake support DMs asking for seed phrases, impersonator channels promising airdrops, lookalike bot handles capturing pasted private keys. The bot should: refuse seed phrases (the only legitimate import is base58 keypair or CLI JSON), refuse to ever DM users asking for credentials, publish a canonical handle so users can verify they're talking to the real bot, and never operate from a channel that isn't the operator's own. If your bot allows seed-phrase import, the answer is no — there is no scenario where a trading bot legitimately needs your seed.

MoonHydra's Answers

Operator-encrypted dedicated wallet (AES-256-GCM at rest, master key in operator env only). Key export pending (Phase 3 — currently burner-only by design; /withdraw signs SOL transfers off-platform). Pino redactor strips encryptedKey / iv / authTag / privateKey / MASTER_ENCRYPTION_KEY from every log. Withdrawal password (scrypt) + TOTP 2FA + 5-attempt lockout + 15-minute cooldown + TOCTOU destination freeze. RugCheck buy gate (default 500, configurable via /security). Public changelog dated to the day, every PR public, incident-reporting email at security@. Burner-wallet recommendation in /start onboarding. Seed phrases refused; only base58 / CLI JSON import accepted, DM-only with auto-delete. Single canonical handle: @moonhydrabot.

For the full breakdown of our security model see moonhydra.com/security. For what we explicitly refused to ship and why, see our kill log.

The Checklist (TL;DR)

1. Does the operator explain custody in one paragraph?
2. Can you export your private key to Phantom / Solflare / CLI?
3. Is there a redaction config or stated policy for decrypted keys in logs?
4. Is the withdraw flow gated by password + 2FA with brute-force lockout?
5. Is there a configurable RugCheck score gate on /buy?
6. Is there a public dated changelog and visible PR history?
7. Does onboarding push burner discipline (or is the bot positioned as a vault)?
8. Does the bot refuse seed phrases and publish a canonical handle?

Print this list. Run it on any bot you're evaluating. The bots that pass all eight are not necessarily safe — but the bots that fail three or more are almost certainly not. Ready to set one up correctly from scratch? The complete setup guide covers wallet generation, key settings, and first-trade configuration in order.