Custodial vs Non-Custodial Volume Bots

The difference in one sentence

A custodial volume bot can move your funds without you approving the individual action, because it holds a signing key or an on-chain approval that lets it act for you. A non-custodial one cannot: every transfer needs a signature that only your key can produce. Interface, venue coverage and fee structure all sit on top of that fact.

Both models present the same surface to a buyer, which is why the distinction gets lost so easily. A connect-wallet button, a configuration form and a live log look identical whether the engine signs with a key you control or with one an operator generated for you. Settle custody before you compare venue lists, because a pricing dispute costs the fee while a custody failure costs the balance.

Why the word non-custodial is used loosely

Non-custodial has drifted into marketing vocabulary and away from a testable claim. Vendors use it to mean that they never request a seed phrase, that keys are generated inside your browser, that keys are encrypted at rest on their servers, or that keys can be exported on demand. The question that actually separates the models is which party can produce a valid ed25519 signature for the wallets holding your funds.

Encryption is the phrase that hides the most. A key encrypted with a passphrase you supply and decrypted only inside your browser session is a different animal from a key encrypted with a server-side secret and decrypted by the engine whenever a run starts. Both are described as encrypted at rest, and only the first arrangement removes the operator from the signing path.

Interface choice adds its own confusion, because a chat-based tool and a hosted console imply different key-handling defaults long before anyone writes a policy page about it; that comparison is set out in the trade-offs between a Telegram bot and a web console.

The four custody models

Almost every volume product on Solana falls into one of four arrangements, and they are not a quality ranking. A carefully run custodial service can be less dangerous in practice than a self-hosted setup abandoned on an unpatched server. What the models tell you is which failure you are exposed to, so you can decide whether that particular failure is one you could absorb.

Fully custodial deposit

You transfer SOL to an address the operator controls, and everything runs from wallets it owns. Your balance becomes a number in someone else's ledger, and withdrawal is a request rather than an action you can take alone. This is the easiest model to use and the only one where a single decision by another party ends your access entirely.

Delegated signing

You keep your own wallet and sign one approval that lets another address move tokens from a specific token account. On Solana this is the SPL Token approve instruction, carrying an approved amount alongside the delegate address. The permission is narrower than a shared key but durable: it stays in force until revoked or exhausted, and nothing reminds you that it exists.

Key in your browser or on your machine

The engine assembles transactions and your wallet signs them, through a browser extension or a local keypair the software reads at runtime. The operator never gains the ability to sign for you. Exposure shifts to transaction content: you are trusting that what the wallet asks you to sign matches what the interface described, and blind approval undoes the arrangement.

Self-hosted with your own keys

You run the engine on infrastructure you control and the keypair files never leave it. The operator sells software rather than a service that touches money, so no address on their side could receive your balance. What you gain in custody you pay for in operational work, and that hosting decision is examined in the comparison of self-hosted and managed engines.

The custody matrix

Read this matrix across a row rather than down a column. The row you occupy determines the shape of a bad outcome, the party whose behaviour you depend on, and whether the chain shows you anything useful afterwards. Where a product straddles two rows, and several genuinely do, assume the weaker of the two until the operator disproves it.

Products rarely announce which row they occupy. Solana volume automation tools sit at different points on this matrix, and the page selling one is rarely where its custody model is written plainly, so you usually infer the row from what the interface asks for, not from a specification.

The last column is the one buyers skip and later regret. Recovery is not a support promise, it is a property of the arrangement: either you hold a key that can still move the funds or you do not. Everything in between depends on somebody choosing to help you after the money has already moved.

A permission check for a wallet you already connected

If you have already clicked connect on a product you never classified, work through this before funding anything further. The sequence assumes nothing about the vendor and reads the chain directly, which is the only source a support agent cannot reword. Keep the order, because the later steps depend on knowing which token accounts exist.

1. Open the wallet in an explorer, not in the product. A vendor dashboard shows what its own database believes; an explorer shows what the chain records. Use the public wallet address and keep that tab open throughout.
2. Inventory the token accounts. Every SPL token you hold lives in its own token account with its own owner field. List all of them, including tokens you stopped caring about, because a forgotten account can still carry a live approval.
3. Read the delegate field on each token account. A token account carries an optional delegate address and an approved amount. If either is populated and you cannot name the address, treat it as unexplained rather than as harmless leftover state.
4. Check the freeze authority on each mint. A token account can be frozen only when the mint has a freeze authority set, and only by whoever holds it. That is a property of the token you are trading, not of the bot.
5. Revoke every approval you cannot account for. The SPL Token revoke instruction clears the delegate on one token account. It is a transaction, so it costs a signature and the base fee of 5,000 lamports, sent by the account owner.
6. Confirm the revoke by re-reading the account. Do not treat a confirmation message in an interface as evidence. Reload the token account in the explorer and check that the delegate field is empty and the approved amount is zero.
7. Decide whether the key itself is still trustworthy. Revocation fixes an approval, never a shared key. If a private key or seed phrase was ever pasted, uploaded or generated by somebody else, the only remedy is a new keypair.

What a delegate approval actually permits

An approval is set per token account and per amount through the SPL Token program, and cleared by the matching revoke instruction. It does not extend to other tokens you hold, to token accounts you open later, or to native SOL, which sits in a system account and moves only when the owning keypair signs. The program behaviour is described in the Solana developer documentation.

Two properties catch people out. Duration: an approval persists until revoked or spent, so one granted for a single test run is still live months afterwards. Amount: an approval can be set far above anything a run needs, and an interface requesting an enormous number is asking for permission it has no stated plan to use.

The funding problem when a run needs many wallets

Volume work usually means many wallets rather than one, which turns custody from a yes-or-no question into an inventory question. Each additional wallet is another ed25519 keypair existing somewhere: in browser storage, in a file on a server you rent, in a database column belonging to the operator, or in an encrypted blob whose passphrase one of you holds.

Funding those wallets commits real money to accounts only a keyholder can unwind. A system account needs 890,880 lamports to be rent exempt and an SPL token account needs 2,039,280 lamports for its 165 bytes of data. That reserve returns when the account is closed, and closing is a signed instruction, so only whoever holds the key can reclaim it.

Put a blunt version to the vendor: after the run finishes, who closes the sub-wallet accounts, and where does the returned reserve go? A product that has considered the question will name a sweep procedure and a destination address. One that has not will call the balance handled automatically, which describes a database entry rather than a transaction.

What you can verify on chain afterwards

Solana settles publicly, so much of what a vendor tells you is checkable without their cooperation. Every transaction carries a signature you can look up, a fee payer, an ordered list of instructions and the accounts it touched. Explorers such as Solscan present that record, and an operator who will not hand over signatures is choosing not to be checked.

Four things are worth confirming after a run. Which address paid the fees, because that reveals whose keypair signed. Which addresses received transfers, because a sweep to an address you cannot identify is the clearest custody signal available. Whether any token account still shows a delegate. And whether the interface transaction count matches the on-chain signature count, including failures, since the 5,000 lamport base fee is charged either way.

What the chain cannot tell you is intent. It shows that an address moved tokens; it never shows whether the operator meant to, whether a key leaked, or whether one employee acted alone. That is why the custody model matters more than an incident history: the model bounds what the worst version of any of those stories costs you.

Questions that reveal the model

These questions are diagnostic rather than confrontational. Each has an answer shape that places a product on a row of the matrix, and each one is awkward to answer vaguely. Send them in writing where you can, because a written answer can be checked against the chain later, and because a refusal to put custody in writing is itself an answer.

• Which address signs the transactions in a run, and can you show me one of those signatures on an explorer?
• Where is the private key for each sub-wallet stored, and which of your systems are able to read it?
• If I stop paying tomorrow, can I still move the funds sitting in the wallets your tool created?
• Does the tool request an SPL Token approval, and if so, for which amount and on which token accounts?
• Can I export every keypair the run generated, in a format I can import into a wallet elsewhere?
• Who closes the sub-wallet accounts after a run, and which address receives the returned rent reserve?
• What happens to my funds if your infrastructure is unavailable for a week?
• Has any part of your system ever needed my seed phrase, and under what circumstances would it ask?

Record the answers somewhere durable rather than in your head. Custody is one property among several worth grading before payment, and the full scoring sheet with its bands and evidence requirements belongs to the nine criteria used to grade a volume tool. Here a single result is enough: the row you are in, and whether the vendor agrees.

Residual risk you cannot remove

Holding your own keys removes the operator from the signing path, not the machine that stores the key, the extension that renders the prompt, or the moment of impatience when a signature request appears mid-run. Judge what remains against the size of what you are willing to lose: a custodial tool holding a shruggable amount is a reasonable trade, the same tool holding a treasury is not, and the tell is usually the surrounding behaviour catalogued in the warning signs worth checking before you pay.

Custody is the first property this desk grades, and the rest sit alongside it in the criteria section. Settle this one first regardless. A tool that scores well on venue coverage, fee structure and reporting is still a tool you have handed a balance to, and no amount of good behaviour elsewhere converts a deposit address into a key that you hold.

Frequently asked questions