Every guide to running a trading bot contains the same security paragraph. Create an API key on your exchange. Tick "enable trading". Do not tick "enable withdrawals". Paste the key into the bot. You are now safe.

You are not. You are protected against one attack, and while you were reading that paragraph it changed the subject. It answers the smallest of the three custody questions and lets you stop there, which is most of the reason it appears in every guide.

Here are the other two. Both are checkable in about five minutes, on any bot, including the one you are running right now. One of them is going to be uncomfortable.

1. The permission you decided was harmless

A trade-only API key is a real control and it is worth using. It also has a shape that is easy to misread.

What it prevents: an attacker who steals the key cannot send your coins to an address they own.

What it does not prevent: losing the money by trading it. A key with trade permission can buy an illiquid asset with your entire balance, sell it into a book with no depth, and repeat. Nothing in that sequence is a withdrawal. Your balance leaves through the order book rather than through the door, and the exchange records every step as a legitimate instruction you authorized. The pattern is old enough to have been written up here in 2018, in How your trading API keys can be used to drain your funds.

There is also a party you have added to your threat model without noticing. Whoever runs the bot now holds a working credential to your exchange account. It sits in their infrastructure, not yours. If their service is breached, your key is in the breach. Ask any bot vendor where keys are stored, whether they are encrypted at rest with a key the operators themselves cannot read, and whether an IP allowlist is enforced on their side. The answers are usually available and occasionally alarming. Olena Usachova walks through what that credential actually hands over in Not Your Keys, Not Your Coins, or Consequences of Using API Keys for Trading.

So "cannot withdraw" is not "cannot lose", and "my key" is not "only mine". That is question one, and question one is the easy one.

2. You do not own a balance. You own a promise.

This is the question the API key paragraph distracts from.

While your bot is running, your coins sit in an account on a venue. What you see on the screen is a number in that venue's database. It is not possession, it is a claim: the venue owes you that amount, and you find out what the claim is worth on the day you try to collect.

Most of the time collection works and the distinction feels academic. It stops being academic in exactly the situations you bought the bot to survive. Withdrawals get paused during volatility, which is when your profit exists and when you want it. An account gets frozen pending a review, and reviews take as long as they take. In an insolvency, the ledger entry becomes an unsecured claim in a proceeding, and your place in that queue is decided by law rather than by your trading.

Notice that none of this is a criticism of the bot. The bot merely gave you a reason to keep a balance parked somewhere for months. The profit it reports is a liability entry until you have moved it, and a dashboard number is not custody.

Say the slogan out loud, the one everyone in this industry repeats. Then look at your dashboard.

3. "Non-custodial" is a word, not a property

The on-chain answer to all of the above is a bot that trades from your own wallet, so the coins never sit anywhere you cannot reach. Good. Now watch the word get used against you. Every project in the category writes "non-custodial" on its landing page, including the ones for which it is not true, and a word that everybody claims tells you nothing about anybody.

Replace the adjective with five properties you can verify without asking anyone.

Where does settlement land? Open one real transaction from the bot and read the token transfer events. Look at the destination address of the output leg. Either it is your address or it is not, and no amount of documentation outranks that field.

What did you approve? Every on-chain bot needs an allowance to move the token it trades for you. An unlimited approval to a contract means that contract can pull that token from your wallet at any time in the future, whatever the docs promise. You can list your live approvals on a tool such as revoke.cash and revoke the ones you no longer use. Do this for every dapp you have ever touched, not only bots.

Is the contract upgradeable? If the address you approved is a proxy, the code you reviewed today can be replaced tomorrow by code you have never seen, usually by a single privileged transaction. On an explorer, a proxy shows up as a separate "Read as Proxy" tab and an implementation address. An upgradeable contract is not automatically bad. It is a different trust model: you are trusting the upgrade key, not the code.

Which functions are privileged? Read the source and look at every function guarded by an owner check. The question is narrow and answerable: can any of them move a balance that belongs to someone else? Pausing, fee setting and parameter changes are ordinary. A privileged path that touches user funds is the whole ballgame.

Does the published source match the deployed bytecode? Explorers distinguish an exact match from a similar match. A similar match means the source you are reading is close to what runs, not provably identical. Reading the wrong source carefully is worse than not reading it at all.

4. Five minutes. Run it on your own bot first.

For any on-chain trading bot, including the one I built:

1. Get the contract address the bot asks you to approve. If you cannot find it before connecting a wallet, stop here.
2. Open it on the chain's explorer, Contract tab. Confirm the source is verified and that it says exact match.
3. Check whether there is a proxy tab. If there is, find out who holds the upgrade key and under what delay.
4. Search the source for the owner modifier and read every function that uses it. Ask the narrow question: can this move a third party's balance?
5. Open one settled trade and read the transfer events. Confirm the output leg lands at the user's own address.
6. After you stop using it, revoke the allowance. An unused approval is a standing permission.

That checklist costs nothing and it disqualifies a surprising number of products at step 2.

5. Disclosure

I build btcbot.io, a trading bot on BNB Chain, so read this section as interested testimony rather than as neutral reporting.

I wanted a bot for myself and did not want to answer question two, so the design starts from the constraint instead of adding it later: you sign a mandate from your own wallet, the bot builds and submits the trade, and settlement lands back at the address you signed from. There is nothing to deposit, so there is no balance of mine for anyone to pause.

That is a claim, and the point of this article is that claims are worth what their verification is worth. The router is 0x600D173c359DB44aFef10b38cA2D7Cad0A320b28 on BNB Chain, contract name BtcbotRouterV3, open source and verified (exact match) on BscScan. It is not behind a proxy. Run the five steps above against it. Step 5 is the one I would run first.

And if you would rather look than read, the trades are visible as they settle at btcbot.io/demo. No signup.

6. The uncomfortable part

The API key checkbox is real security, and it answers the least important question. It has also been doing your thinking for you. Before you run any bot, ask the other two questions it talked you out of: what can this credential do to my money without moving it, and whose ledger is my balance actually sitting in? Then verify the answers yourself, because in this category the difference between a product that is safe and a product that says it is safe is usually four clicks on a block explorer.