The three custody models and their worst cases
Every sniper bot has to sign transactions, and signing requires a private key. How that key is handled is the entire safety question, and it collapses into three arrangements.
| Model | Who holds the key | Worst case |
|---|---|---|
| Custodial | The service | Everything in the account, at any time |
| Delegated key | The service holds a key you generated | Everything in that one wallet |
| Non-custodial | You, in your own wallet | A transaction you approved |
The distinction people miss is between the first two. A service that asks you to deposit into an address it controls is custodial no matter how the interface is worded. A service that runs a key you created and funded separately is not the same thing: the loss is capped at what you put in that wallet.
Five questions to ask before funding anything
- 1Who generates the key, and whereA key generated in your browser or on your machine is a different proposition from one generated on a server you cannot see.
- 2Can I export itIf you cannot export the key, you do not control the wallet, whatever the marketing says. Exportability is the test.
- 3What happens if the service disappears tomorrowA setup where your funds are stranded because a website went offline is a setup with a single point of failure that is not on-chain.
- 4What is the key allowed to signTrading is one permission. Transferring out to an arbitrary address is another. They are not the same and should not be bundled.
- 5Is there a withdrawal path that does not go through the interfaceIf the only way out is a button on a site, the site is a dependency your money cannot survive losing.
None of these require technical knowledge to ask. All of them have short, factual answers if the design is sound, and evasive ones if it is not.
The separate wallet rule
Whatever the custody model, the single most effective protection costs nothing: never point a sniper at a wallet holding anything you are not willing to lose entirely.
This is not pessimism about any particular tool. It is the recognition that a trading wallet is exposed to a wide surface, including the token contracts it interacts with, and that surface has nothing to do with the bot's integrity.
What a sane setup looks like
- A dedicated wallet created for this and nothing else.
- Funded with the capital the strategy actually needs for a week, not a reserve.
- Profits swept out to a wallet the bot has never seen.
- Your main holdings in a wallet that has never signed anything for a trading tool.
What the key is actually allowed to sign
A key is not a permission level, it is total authority over its wallet. That is why the scoping has to happen at the wallet boundary rather than inside the application: whatever the interface offers, a key that can sign can sign anything.
This is also why token approvals deserve attention. Interacting with a new token contract can leave standing permissions behind, and those outlive the trade. A wallet used for sniping accumulates relationships with contracts that were, by definition, not vetted by anyone before you touched them.
| Concern | Where it is solved |
|---|---|
| Service could move funds | Custody model and key export |
| Token contract could be malicious | Screening before entry |
| Standing approvals accumulate | Rotating the trading wallet periodically |
| Loss exceeds intent | Funding the wallet with a bounded amount |
The screening side of safety
- Avoiding rug pullsFour mechanisms and a 60 second manual check
- The full sniper bot guideWhere screening sits in the execution path
- How to judge a sniper botTurning marketing claims into checkable questions
- Are sniper bots profitableWhy prevented losses are most of the value
Red flags that end the conversation
- A seed phrase requested anywhere, for any reason. There is no legitimate version of this.
- Deposits to an address the service controls, described as your balance.
- No way to export the key of a wallet you are told is yours.
- Guaranteed returns, or any specific profit figure presented as expected.
- No answer to what happens if the service goes offline.
- Support conducted only in direct messages, with no written documentation of how custody works.
The first item is worth repeating on its own. A tool needs a key to sign transactions for one wallet. It never needs the phrase that regenerates every wallet you own. Any request for it is the end of the evaluation, regardless of what else the product does well.
Questions people ask
These come up in the ticket queue often enough to answer once, properly. If yours is not here, send it over and it probably ends up on this page.
The trading risk is bounded by position size and you control it. The custody risk is not, and it is decided by who holds the signing key. A non-custodial setup with a separate, limited wallet reduces the worst case to what that wallet holds.
Key takeaways
- Custody is the unbounded risk; trading risk is bounded by position size and chosen each time.
- Three custody models exist, and the difference between a delegated key and a deposit address is large.
- Exportability is the test of whether a wallet is really yours.
- Fund a dedicated wallet with what the strategy needs and sweep profits out regularly.
- A key is total authority over its wallet, so scoping happens at the wallet boundary.
- A seed phrase request is the end of the evaluation, no matter how good the product looks.