What a trading bot can actually do with your exchange API keys
Every automated trading service that connects to a centralised exchange asks for the same thing: an API key with trading enabled and withdrawals disabled. The advice around it is consistent and correct — never enable withdrawal, whitelist the service's IP addresses, keep two-factor authentication on. 3Commas publishes exactly this guidance, and so does every reputable operator in the category.
It is good advice. It is also narrower than most people hear.
"The bot cannot withdraw your funds" is true. Most readers translate it into "the bot cannot cause me a loss," and that second sentence is not true. Understanding the gap between them is the whole point of this page.
What a trade-enabled key permits
A key with trading permission can place and cancel orders against your balance. That means it can decide what you hold, and at what price, for as long as the key is live. It cannot move assets off the venue, but it can change every asset into a different one.
The distinction that matters is between theft and control. Withdrawal permission is what enables theft: assets leave, and they are gone. Trading permission enables control: assets stay on the venue under your name, while someone else decides their composition. A key that can only trade is meaningfully safer than one that can withdraw, and it is not the same as a key that can do nothing harmful.
The uncomfortable case is a thin market. If an attacker holds a trade-only key on your account and can also place orders of their own on a venue with little depth, they can arrange for your balance to buy what they are selling, at a price they choose. Nothing was withdrawn. Your assets are still on the exchange, still yours. They are simply worth less, and the counterparty was the attacker. This is why the security guidance emphasises IP whitelisting so heavily: the real defence is that the key cannot be used from anywhere else, not that trading permission is inherently safe.
Two trust assumptions, not one
Connecting a bot to an exchange account stacks two separate questions:
Does the exchange hold your assets faithfully? On a centralised venue, the exchange holds the keys. Your balance is a database entry representing what they owe you. This has nothing to do with automation — it is true whether or not you ever connect a bot — but it is the base layer everything else sits on.
Does the operator handle your key faithfully? The service stores a credential that can trade your balance. You are trusting their infrastructure, their access controls, and their incident response.
The second assumption is the one automation adds. The first was already there.
What the on-chain model changes, and what it does not
An on-chain execution model removes the first assumption and reshapes the second. Assets sit in a wallet whose keys you hold; nobody has an obligation to honour a balance because there is no balance to honour, only tokens at an address. The operator holds a scoped signing authorisation — a delegated session signer attached to the wallet, governed by a policy the operator defines — that can swap allowlisted assets within an amount you set, and nothing else — no transfer, no withdrawal, no reach into anything you did not allocate. The allowlist and the cap are applied by the operator's executor — not by the chain, and not by the signing provider. That is a narrower promise than an account-wide key, and still a promise.
That is a genuine reduction in what has to go right. It is also not a claim that nothing can go wrong. The operator can still decide what you hold within its scope, which is the same category of control described above. Scope narrows the blast radius; it does not eliminate it. Anyone describing an on-chain model as risk-free is selling you something.
Tradevo works this way — algorithmic strategies executing on Base from a wallet whose keys the user holds, through a scoped signing authorisation governed by a Tradevo-defined policy. It is one implementation of the pattern, not the pattern itself.
When API-key bots are the better choice
There is one property the API-key model has that most on-chain implementations, Tradevo included today, do not.
You can delete it yourself, instantly, without the operator's cooperation. Deleting an API key is a single action inside your own exchange account. It takes effect immediately, it does not depend on the operator's servers being reachable or their code behaving correctly, and no one can talk you out of it. That is a real kill switch held by the person who should hold it.
Cancelling stops the strategy immediately; Tradevo's signer is then removed by us, best-effort, rather than by something you trigger yourself. You can export your wallet at any time, which leaves us zero residual access — but that is an exit, not an off-switch. If having a unilateral off-switch is your priority, an exchange API key you can delete is the stronger arrangement, and we would rather say so here than have you discover it later. We think an account-level permission a user can disable on-chain without us is where this ought to end up; it is not where we are today.
Three more cases where the API-key route is simply the right tool:
- You trade assets that only exist on centralised venues. Plenty of pairs have no meaningful on-chain market. No amount of architecture fixes that.
- You need order types an on-chain venue cannot express. Anything depending on a matching engine — resting limit orders deep in the book, complex conditionals — belongs where the matching engine is.
- You already accept exchange custody deliberately. If your assets live on a venue for reasons you have thought about, adding a self-custody layer for the automation alone buys you less than it costs in complexity.
How to decide
Ask one question of any automated trading service, and do not accept a slogan as the answer: who can move the assets, and who has to cooperate for that to stop?
For an API-key bot the answer is that the exchange holds them, the operator can rearrange them, and you can end it unilaterally by deleting the key. For an on-chain model it is that you hold them, the operator can rearrange them within a fixed scope, and ending it depends on the operator's mechanism — so ask precisely what that mechanism is, and whether it works if the operator does not cooperate.
Both answers are defensible. Neither is "your funds are safe." Any service that gives you the second answer without the detail has told you nothing.
Tradevo Technologies builds evidence infrastructure for systematic trading. Nothing here is investment advice, and no part of this page describes how any strategy performed.