Keys, wallets and bot permissions: sizing the blast radius

Three custody models

Note what the middle row does not say. It does not say the provider is dishonest. It says that once a private key has been transmitted, its security is bounded by the weakest point in an environment you cannot inspect, including their logging, their staff, their dependencies and any future breach. A key is not a permission that can be scoped or withdrawn; it is the whole authority, forever.

The third row is the safest and it is genuinely incompatible with the fastest strategies. That is a real trade-off, not a solvable problem, and the honest response is to choose the strategy that fits the custody you are willing to accept rather than the reverse.

What connect wallet actually grants

Connecting a wallet is widely misunderstood in both directions. Some readers think it hands over funds; others think it is entirely safe. Neither is right.

• Connection shares your public key. That is all. It lets a site read your address and your public balances, which are already public.
• Message signing proves control. A signature over a plain message is standard for authentication and cannot move funds. Read the message anyway: it should be human-readable and should not be an encoded transaction.
• Transaction signing is the only thing that moves anything, and it is per transaction. Every approval is a discrete decision.
• Batch signing exists. A site can request signatures for several transactions at once. This is legitimate for multi-step operations and it is also the point at which a user habitually clicking approve stops reading.
• Auto-approve settings remove the protection. Some wallets offer to sign automatically for a trusted site or within a session. That converts model three into something closer to model two for the duration.

The practical guidance follows directly: connect from a wallet that holds only what you are willing to expose to a mistake, read what you are signing when the amount is material, and treat any prompt asking for a seed phrase or a private key as an attack without exception. No legitimate application needs either.

Delegates, approvals and account authority

Between connection and full custody sits a mechanism most users never look at. A token account can appoint a delegate that is permitted to move up to an approved amount out of that account, without a further signature from the owner.

This is a normal part of many program interactions and it is not sinister in itself. What matters is that a delegate approval persists after the interaction ends. A large approval granted once and forgotten is a standing permission over that token account for as long as it remains in place. The corresponding revoke instruction removes it, and periodically reviewing and revoking delegates on token accounts you still hold is cheap maintenance that almost nobody performs.

There is a second, sharper instruction to know about. The token program allows the authority over a token account to be changed. A transaction that alters account ownership does not look dramatic in a wallet prompt, and its effect is total for that account. This is why the advice to read transactions before signing is not merely about checking amounts: the dangerous instruction may not involve an amount at all.

A wallet tier architecture

Segmentation is the only structural defence that survives operator error. The model below is deliberately simple and covers most single-operator setups.

The rules that make the architecture work are simple and unforgiving. Funds move down the tiers, never up automatically. Nothing above the operating tier is ever pasted into anything. An operating wallet is topped up on a schedule rather than kept full. And a burner that has interacted with an unevaluated tool is never promoted, because it is now permanently in the untrusted set.

There is a genuine cost. Each additional wallet needs fee headroom and rent-exempt token accounts for the mints it touches, so segmentation immobilises capital in proportion to the number of wallets. The tension is sharpest wherever Solana volume automation is involved, because that class needs a wallet fleet by design and every wallet in it sits in the operating tier by definition. That arithmetic is worked through in the cost model, and it is the reason to choose a tier count deliberately rather than creating wallets indefinitely.

Blast radius, quantified

Blast radius is the maximum loss if a specific credential is disclosed right now. Writing it down for each credential you hold takes ten minutes and changes behaviour more reliably than any amount of general advice.

Two rows deserve emphasis. The seed phrase row is why a bot should be given a single derived key rather than a seed: handing over a seed hands over every wallet in the tree, including ones created later. The host access row is why compromise of a machine is not a wallet incident but an environment incident, and why rotation must cover every key that machine has ever seen, not just the ones currently in use.

Where a key may and may not live

Ranked from acceptable to disqualifying for an operating-tier key:

• Injected at runtime from a secret manager or the OS keychain, never written to disk in plaintext. Best practical option for an automated system.
• An encrypted file with a passphrase supplied at start-up. Workable, and it means an unattended restart requires a human, which is a feature more often than a nuisance.
• An environment variable in a process manager configuration. Common, acceptable if the host is controlled and the configuration is not backed up somewhere unexpected.
• A plaintext file in the project directory. Tolerable only for a burner, and only if the directory is genuinely outside version control.
• Anywhere inside a repository. Disqualifying. Commit history is permanent and scanned continuously by automated tooling.
• In a log line, an error report, or a support chat. Disqualifying. Logs travel further than anyone expects, especially into third-party aggregation.
• Pasted into a hosted interface. Disqualifying for anything above burner tier, for the reasons in the custody table.

One supply-chain note. A bot process holds keys in memory, so every dependency in that process can read them. Pinning dependency versions, reviewing what a package actually does before adding it, and keeping the trading process narrow are security measures rather than engineering preferences. The dominant real-world compromise of self-hosted setups is not cryptographic; it is a package or a copied script that nobody read.

Revocation and rotation runbook

Under stress, order matters more than completeness. Contain first, investigate later.

1. Stop the process. Kill the bot before anything else so it cannot compete with your recovery transactions.
2. Move remaining balances to a wallet whose key has never existed on the affected host. Send SOL last, since you need it to pay fees for the token transfers.
3. Revoke delegates on any token accounts that remain, and check for authority changes on accounts you still control.
4. Disconnect sessions and disable any auto-approve settings in every wallet that interacted with the affected tooling.
5. Rotate every key the host has ever held, not only the one you believe was exposed.
6. Rebuild the host rather than cleaning it. A cleaned machine is an assumption; a rebuilt one is a fact.
7. Only now reconstruct the timeline from explorer history, and write down which control would have prevented it.

Practise steps one and two once, deliberately, with a small amount. The first time you attempt an emergency drain should not be during an actual emergency, when you will discover that the wallet has no SOL for fees because you moved it first.

Hosted and chat-based bots

Bots operated through a chat interface are popular because they remove every setup step. The custody consequence is specific and worth stating plainly: if the service can execute a trade for you while you are asleep, it holds a key that can do so. Whether it was generated for you or imported from you changes the story only slightly, because in both cases the operator's infrastructure can sign.

That is not automatically unacceptable. It is a decision about how much value to place behind a counterparty you cannot audit, and it should be sized accordingly. Two rules make the model survivable: keep the balance under such a service at a level you would be willing to write off entirely, and withdraw profits on a schedule rather than letting a balance accumulate because the interface is convenient.

Also consider the account layer. If access is protected by a chat account, then the security of your funds is the security of that account, including its recovery path and the phone number attached to it. That attack surface is entirely outside the blockchain and it is the one most frequently used.

Operational hygiene checklist

• Automation never receives a seed phrase, only a single derived key.
• Treasury funds sit behind a hardware signer or a multisig, and never touch a bot host.
• Operating wallets are topped up per session rather than kept full.
• Every wallet has a written purpose and a tier; unlabelled wallets are closed.
• Keys are injected at runtime, never committed, never logged.
• Log output is filtered for key-shaped strings before it leaves the host.
• Dependencies are pinned, and the trading process runs the minimum set needed.
• The bot host does nothing else and is not used for browsing.
• Delegates are reviewed and revoked on a schedule.
• Auto-approve is disabled in every wallet used for manual review.
• An emergency drain has been rehearsed with a small balance, fees included.
• Withdrawals from any hosted service happen on a schedule, not when convenient.
• Every credential has a written blast radius and a stated containment step.
• Keys are rotated routinely, not only after an incident.
• A burner that has touched an unevaluated tool is never promoted to a higher tier.

None of this makes automation safe. It makes the maximum loss from any single mistake a number you chose in advance rather than one the incident chooses for you, which is the only meaningful definition of risk control available to an operator working alone.