An API key is a duplicate of your account

A trading bot does not log into your account the way you do. It does not open a browser, type a password or enter a two-factor code. It signs requests with an API key, meaning an identifier, a secret, and sometimes an extra passphrase, as is the case at Bitget.

The benefit is obvious: the program can read a balance and place an order in a fraction of a second, with no human involved. A delta-neutral carry that must open a spot buy and a short on the perpetual at the same time cannot wait for someone to click two buttons.

The downside is less intuitive. A connection made with an API key does not trigger the usual alerts. Binance spells this out in a security article published in April 2026: the system treats the activity as an action authorised by the account owner. No "new login from an unknown device" email, no suspicious login history. A leaked key is silent, and that is exactly what makes it dangerous.

For that reason, an investor should look at one thing before handing capital to an automated tool: the exact permissions of the key they are asked to create.

Permissions, from the most harmless to the most dangerous

Exchanges split access into several levels. The names change from one platform to another, the logic does not.

  • Read: view balances, positions, order history and fees. Nothing can be modified. A dashboard or a tax tool needs only this.
  • Trade: place and cancel orders. This is the permission a bot needs in order to work.
  • Transfer: move funds between your own sub-accounts or internal accounts. Useful for treasury, useless for a strategy.
  • Withdraw: send funds to an external address. This is the only right that takes money out of the exchange.

Bitget documents these four families plainly in its API documentation. Binance describes three, and calls withdrawal the most dangerous permission, with direct and irreversible access to assets.

The difference between those lines is not theoretical. It separates two risks that have nothing in common: losing money because the strategy is wrong, and losing your entire capital because a key leaked.

Why the withdrawal right changes the nature of the risk

Without a withdrawal right, the worst case is still a bad trade. An attacker who steals a read and trade key can open absurd positions, close them at the wrong moment, burn fees. The damage is real, but it is capped by the balance and above all reversible: you delete the key, you take back control, the funds are still in the account.

With a withdrawal right, there is no scenario left, only a single action. One API call is enough to empty the account to an external address. An on-chain transaction cannot be undone. Exchange support does not refund an operation signed with your key.

That is the dividing line to remember: a trading key steals time and performance, a withdrawal key steals capital.

Platforms know it. At Bitget, an API withdrawal is only possible from a previously authorised IP address. At Binance, API withdrawal is also conditional on an IP allowlist. Those locks reduce the risk, they do not remove it: if the key leaks from your own server, your own server is the authorised address.

A delta-neutral carry never needs to withdraw

This is the most concrete point when judging a carry service.

Recall the mechanism. A delta-neutral carry buys the asset on spot and sells the same asset on the perpetual contract. The two positions cancel each other out in price sensitivity. What you collect is the funding rate, the periodic payment that short positions receive when the perpetual market is bullish, meaning when leveraged traders pay to stay long.

To run that strategy, an engine needs to:

  • read the balance, the positions and the current funding;
  • place and cancel orders on spot and on the perpetual;
  • sometimes adjust leverage or the margin mode of a symbol.

None of those operations requires sending funds outside. Deposits are made from the exchange interface, with a password and two-factor authentication. Withdrawals too, and that is how it should stay: they must remain a human action, performed by the account owner, never by a program.

A properly configured bot key therefore looks like this: read enabled, trade enabled, transfer disabled, withdrawal disabled, the server IP allowed, and one separate key per use.

"No withdrawal" does not mean "no risk"

It would be dishonest to stop there. Binance describes a specific scenario that requires no withdrawal right at all: the attacker uses a very illiquid pair to swap his own tokens against your solid assets, at a price he sets himself. Your key buys, he sells, and you end up holding unsellable tokens instead of your BTC.

The same key can also change leverage, switch the margin mode, close one leg of the carry and leave the other one naked. A hijacked bot does not necessarily steal, it can simply destroy.

Two safeguards genuinely reduce that risk.

The IP allowlist. The key only works from the server you declared. A stolen key then becomes unusable from anywhere else in the world. It is the most effective protection after disabling withdrawals, and exchanges explicitly recommend enabling it. Binance goes further: a key with no IP restriction and no activity for thirty days is deleted automatically.

One key per use. A read-only dashboard must not share the trading engine's key. Separate keys limit the damage of a leak and tell you which component was compromised. Revoking one does not cut off the others.

The questions to ask before handing over a key

A service that manages money automatically must answer this list without hesitation. If an answer is vague, that is already an answer.

  • Which permissions exactly, and why is each one necessary?
  • Is the withdrawal right disabled, yes or no?
  • Is there an IP allowlist, and which address is authorised?
  • Where is the secret stored, and who can read it?
  • Can I revoke the key myself, at any time, without warning anyone?
  • What happens to my positions if I revoke the key while the bot is running?

The last question matters most and is asked least. A revocation must stop the bot, not leave orphan positions unattended. A serious engine documents that behaviour, ideally with a mode that closes the legs cleanly or leaves protective orders in place.

Checking a key in three minutes

You do not need to read code to verify what was created.

  1. In the exchange interface, open API key management. Each key shows its permissions and its allowed IP address. Check the withdrawal box, it must be empty.
  2. Through the API itself, Bitget's /api/v3/account/info endpoint returns the allowed IP, the permission type and the list of granted rights, where withdrawal appears under the name withdraw. If that word shows up in the response, the key is too powerful.
  3. Look at the last-used timestamp and the order history. A key used at hours when your bot is not running deserves an explanation.
  4. Test revocation on a low-importance key before scaling up. You will know in thirty seconds whether the process is simple or requires a support ticket.

That check takes less time than opening an exchange account, and it is worth more than any performance promise.

What this changes in the relationship with a provider

The difference between "hand us your funds" and "give us a limited trading right on your own account" is structural, not commercial.

In the first case, you become a creditor of a company: its balance sheet, its solvency and its honesty determine whether you see your money again. In the second, your assets stay in your account, in your name, and the provider can only place orders within the authorised scope. You can revoke access without asking permission, and you can check the positions at any time from the exchange interface.

That does not make the service risk-free, it moves the risk to where it is visible: the strategy and its execution, not the custody of funds.

One last detail that matters: the passphrase. At Bitget it is chosen by the user and cannot be recovered. If it is lost, the key must be recreated. A provider that asks to keep your passphrase in plain text, or offers to create the key for you during a screen share, is reproducing exactly the scam pattern described by Binance.

Sources

The risks

A well-configured key protects against theft, not against a loss. Delta-neutral carry remains a market strategy: if funding reverses for a long period, the position costs money instead of earning it. The short perpetual can be liquidated if margin is badly sized or if price moves violently, even with a spot leg on the other side. Entry and exit fees, spread gaps and exchange incidents can wipe out several months of return. Platform counterparty risk, settlement risk on the stablecoin used and the operational risk of a software bug do not disappear because the funds stay in your account. Finally, no past figure guarantees a future result, and nothing in this article constitutes personalised investment advice: every situation depends on a time horizon, a risk tolerance and a capital that only the person concerned can assess.