Non-Custodial vs Custodial Solana Trading Bots

Almost every Solana trading bot calls itself "non-custodial". A few even mean it. Behind the marketing copy is a spectrum of actual custody arrangements — from "the bot literally cannot move your funds" to "the operator pools all user SOL into one hot wallet they sign for" — and the difference matters a lot the day something goes wrong. This guide breaks down the four architectures you'll encounter, what each one risks, and how to evaluate a bot's real custody posture before you fund a wallet.

What Custody Actually Means

In TradFi, "custodial" describes a third party that legally holds your assets — your broker, your exchange, your bank. In crypto, the line is blurrier because the legal layer is mostly absent. A bot is custodial if there is some pile of private-key material that the operator controls, and signing access to your funds depends on the operator's continued cooperation. A bot is non-custodial if you hold the only key that can move your funds, and the operator could disappear tomorrow without affecting your ability to spend.

Between those poles sits the more interesting question: when the bot signs a swap on your behalf, what private-key material is involved, who holds it, and how is it protected at rest? A wallet can be "yours" in a strict cryptographic sense and still be materially custodial if the bot's operator can drain it. The architectures below sit on that spectrum.

The Four Architectures You'll Encounter

1. Pooled hot wallet — "deposit before trading"

Some bots ask you to deposit SOL into a wallet they generated for your account. The signing keypair lives entirely on the operator's infrastructure. They have a single (or sharded) master key that can sign for every user's deposited funds. This is the most operationally efficient design and the most catastrophically risky — a single key compromise drains every user simultaneously.

The marketing tell is the word "deposit" anywhere in onboarding, or any sentence that begins with "we'll generate your trading wallet" without explaining how the key is encrypted, where, and against what threat model. If you cannot export the keypair to an arbitrary Solana wallet (Phantom, Solflare, CLI) and use it elsewhere, you do not actually control it.

2. Operator-encrypted dedicated wallet

A category MoonHydra sits in. The bot generates a fresh keypair per user (or per Hydra Head, in our case), encrypts the private key at rest with AES-256-GCM, and stores the ciphertext in its database. The master encryption key lives only on the operator's infrastructure — not in the repo, not in chat, not in logs. Every swap decrypts the keypair in-process, signs the transaction, and discards the plaintext.

This is materially custodial in the legal-narrow sense: the operator could decrypt your key if they wanted to, and a successful compromise of the operator's master key would let an attacker decrypt all stored wallets. The mitigations against that are operator discipline (no plaintext keys touch logs, ever), audit surface (the encryption is AES-256-GCM, a well-understood primitive, not a homegrown construction), and explicit communication (we tell you this is the model). The win over pooled hot wallets is blast radius: a compromise still requires the attacker to brute- force decrypt every wallet individually if the implementation uses per-wallet key derivation, which they cannot in any reasonable time.

3. User-encrypted dedicated wallet

A small number of bots ask the user to provide an encryption password during onboarding. The bot derives a per-user key from that password via KDF (typically scrypt or argon2id) and uses it to encrypt the trading wallet at rest. The operator stores ciphertext + salt; the password lives only in the user's head.

This is meaningfully better than (2) on paper: the operator cannot unilaterally decrypt your wallet because they don't have your password. The tradeoff is UX — every bot action that requires signing must collect or have cached the password, which means either a session token (still custodial-feeling) or a password prompt on every swap (terrible UX in a chat context). Most bots that ship this model end up caching the password in plaintext at runtime, which collapses the security advantage.

4. Signing relay to user-held wallet

The most genuinely non-custodial architecture. The bot generates unsigned transactions and relays them to the user's actual wallet (Phantom, Solflare) via WalletConnect-equivalent or a Mini App integration. The user approves each transaction in their wallet app. The bot literally never holds key material.

The cost is approval friction. Every swap becomes a two-tap flow: bot proposes, user signs. For research-and-execute traders this is fine. For sniping, auto-buy, copy-trading, and TP/SL — where the entire value proposition is automation that fires while you're asleep — it is unworkable. MoonHydra evaluated this model and rejected it explicitly because auto-trade is the product (/kill-log documents the reasoning).

Evaluating a Bot's Real Custody Posture

Five questions cut through marketing copy. If a bot evades any of them, treat that as the answer.

1. Can you export the keypair? If the bot doesn't offer key export, you don't actually control the wallet. The "non-custodial" claim is meaningless when there's no migration path off the platform.
2. Where is the key stored, and how? The honest answer is one of: "in your own wallet app", "encrypted at rest with [named cipher] using a master key only on our servers", "encrypted with your password using [named KDF]". If the answer is hand-wavy, assume the worst.
3. Is there a single master key the operator holds? For architecture (2), yes — and that should be communicated explicitly. For (4), no. For (1), yes plus the funds are pooled, which is the worst combination.
4. What happens if the operator gets compromised? The right answer involves the words "per-wallet derivation", "HKDF", or "argon2id". The wrong answer is silence.
5. Are private keys ever in logs, memory dumps, or chat history? Every bot's answer is "no", but the audit surface is whether the bot codepaths that touch decrypted keys route through redacted loggers, refuse to print keys to admin DMs, and discard plaintext immediately after signing. MoonHydra uses a Pino redactor for this, refuses to echo private keys back to users, and auto-deletes the user's message during wallet import.

Why MoonHydra Chose Architecture (2)

Architecture (4) — signing relay — is the cleanest custody story in the world and breaks the entire auto-trade product. Pump.fun sniping, copy-trading, TP/SL, DCA, auto-buy, auto-sell — none of them work if every signature needs human approval. We made a deliberate trade: accept the operator-encrypted model with all its disclosure obligations in exchange for the automation that is what most users want from a Telegram trading bot.

The disclosures: AES-256-GCM at rest, master key in operator env only, never logged, never echoed, never sent over Telegram. Encryption verified per-wallet on the audit checklist. The repo is public for anyone who wants to verify the codepath that touches decrypted keys. Burner-wallet recommendation in onboarding so the user's mental model matches the actual custody posture: funds here are at-risk capital, not treasury reserves. Read the full breakdown on moonhydra.com/security or the /kill-log for what we refused to do.

Bottom Line

"Non-custodial" on a Solana trading bot's landing page is almost never the full story. The real question is which of the four architectures the bot actually uses, what the operator can do unilaterally, and how the team communicates the tradeoffs. Pooled hot wallets are catastrophically risky and increasingly common. Operator-encrypted dedicated wallets are the pragmatic default for automated trading bots — fine if disclosed honestly, dangerous if obscured. Signing-relay bots are the gold standard for custody and unworkable for auto-trade. Pick the architecture that matches the trading style you actually have, not the architecture that sounds best in a tweet.