Crypto exchange API key security starts with permissions
Crypto exchange API key security is mostly a permissions problem, and the permission that matters most is withdrawal. For most retail trading bots, withdrawal permission is unnecessary and should stay disabled. If a key with withdrawal rights leaks, your balance can be gone before you finish reading the notification email.
Disabling withdrawal permission prevents the worst outcome outright, which makes it the control worth being most dogmatic about. IP allowlisting is the next most preventive layer, because a stolen key that only works from your own server is largely inert in someone else’s hands. Rotation and rate limit discipline sit behind both, shrinking the window and the blast radius rather than stopping an attack outright.
All of it still matters, because trade-only keys are not harmless: somebody who can place orders on your account can drain most of its value without moving a single coin off the exchange. The mechanism is explained further down, and it is the reason “trade-only means safe” is wrong.
This article is general information only and is not personal financial, tax or legal advice. It does not take account of your objectives, financial situation or needs. Consider your own circumstances and seek advice from a licensed professional before acting on anything described here.
What each permission scope actually does
Exchange permission scopes collapse into four categories: read, trade, margin or derivatives, and withdraw. Each grants a distinct capability and carries a distinct failure mode if the key leaks. Grant the narrowest set your strategy genuinely uses, then re-check after every change. Scope creep is real: people add margin permission for one experiment and leave it enabled for years.
| Scope | What it allows | Who needs it |
|---|---|---|
| Read / view | Balances, order history, fills, open positions | Tax software, portfolio trackers, dashboards |
| Trade / spot | Place, amend and cancel spot orders | Grid bots, DCA bots, signal execution |
| Margin / futures / derivatives | Leveraged positions, borrowing, liquidation exposure | Only strategies actually trading leverage |
| Withdraw / transfer | Moving assets off the exchange or between accounts | Effectively nobody running a retail bot |
Read-only keys deserve more attention than they get. Tax reconciliation tools, portfolio dashboards and analytics services all ask for API access, and most of them only need to read. Give a tax tool a trade-enabled key and you have handed a third party the ability to move your positions.
Margin and futures scopes are the quiet risk. A trade-only spot key limits an attacker to churning assets you already hold. A derivatives key lets them open leveraged positions that can liquidate the collateral behind them.
Some exchanges also separate transfers between your own sub-accounts from external withdrawals. Treat internal transfer rights as a withdrawal permission in disguise, because it lets an attacker consolidate funds into whichever account has the weakest controls.
IP allowlisting is the highest-value control after scopes
An allowlisted key is far less useful to whoever steals it. Many major exchanges let you restrict a key to one or more source IP addresses, so requests from anywhere else are rejected regardless of whether the signature is valid — though availability varies, so check your exchange’s own API settings.
This is straightforward if you run Freqtrade, Hummingbot or a custom script on a VPS with a static address. Keep in mind that rebuilding or resizing an instance often changes the address, which will silently break your bot until you update the allowlist.
It is harder for hosted platforms. Services such as Cryptohopper and Bitsgap execute from their own infrastructure, so the addresses you allowlist belong to the vendor rather than to you, and the vendor can change them as its estate evolves. That still narrows where a stolen key will work, but the key itself sits inside the vendor’s breach perimeter no matter which addresses are on the list. Follow the vendor’s own current instructions, because the process differs between platforms.
Running a bot from a home connection on a dynamic IP is the awkward middle case. You can allowlist your current address and accept that your bot stops when the ISP rotates it, or you can put a cheap VPS in front as a fixed egress point. Some Australian traders route through a VPS in Sydney or Singapore purely to get a stable address.
Two different exchange features are easy to conflate here. A source IP restriction governs where requests may originate, while a withdrawal address allowlist governs where funds may go, and some venues gate withdrawal permission behind one or both. Check the exchange’s current API documentation rather than assuming the two are the same, because controls and wording differ by venue.
How keys actually get compromised
Keys are lost through five ordinary routes: secrets committed to a repository, malicious package dependencies, breached third-party platforms, market manipulation against trade-only access, and infostealer malware on the machine holding the secret. Almost none of it involves breaking cryptography; the realistic failure modes are mundane, and recognising them beats any amount of theory.
Keys committed to a repository
Hardcoding a secret into a strategy file and pushing it to GitHub is the classic. Automated scrapers watch public commits and act very quickly. Making the repository private afterwards does not help, because the secret is already in the commit history and probably already collected.
Compromised dependencies
A self-hosted bot pulls in dozens of packages, and package registries have repeatedly shipped malicious versions that read environment variables and post them to a remote server. Pin your dependency versions, review what a package update actually changes before installing it, and be sceptical of obscure libraries with few users.
Third-party platforms and copy-trading services
Handing your key to a hosted bot means trusting that vendor’s operational security, their staff and their breach disclosure practices. That is sometimes a reasonable trade for convenience. It is only reasonable if the key you gave them cannot withdraw.
The pump-and-dump exit
This is why trade-only keys still need protecting. An attacker with trade access across many accounts buys an illiquid altcoin heavily using those accounts, having already positioned themselves in it, then sells into the buying they just manufactured. Your account is left holding a near-worthless token bought at an absurd price, and nothing was ever withdrawn. It is why a trade-only key deserves the same allowlisting and rotation discipline as any other.
Everyday device compromise
Infostealer malware sweeps browser sessions, saved credentials and plaintext config files. Phishing pages imitating exchange login flows harvest credentials and session tokens. Storing keys in a plain text file called keys.txt on your desktop is a genuinely common mistake among otherwise careful people.
What rate limits mean in practice
Rate limits cap how frequently your bot may call an exchange API, and breaching them gets your requests rejected rather than queued. Tight polling loops across many symbols, or repeated calls to heavy endpoints, exhaust a budget far faster than the raw request count suggests, which most retail traders discover the hard way. Read the actual documentation for your exchange rather than assuming a figure, because the limits vary widely between venues and change without much fanfare.
The important nuance is that some venues weight requests rather than counting them equally, so a single ticker call and a full order book snapshot may draw very differently on the same budget. Where that applies, a bot making a modest number of requests per second can still exceed its budget by repeatedly calling heavy endpoints.
Getting throttled is not a cosmetic problem. Once you are rate limited, cancellations fail, stop adjustments do not land, and a strategy that assumed it could exit a position discovers that it cannot. Repeated violations can result in a temporary ban, which on some venues applies to the source IP rather than the key, and an IP ban takes down every key running from that server. In a fast-moving market that gap is where the losses happen.
The practical fixes are unglamorous. Use WebSocket streams for anything you would otherwise poll, because a subscription costs one connection instead of thousands of requests. Batch order operations where the exchange supports it, and back off exponentially when you receive a throttling response rather than retrying immediately.
Rate limits also affect your security posture directly. Traders who hit limits often “solve” it by spinning up a second key, then a third, and end up with a spread of half-forgotten credentials nobody is tracking. Fix the request pattern instead of multiplying keys.
Rotating keys without breaking your bot
You rotate without downtime by overlapping two keys: create the replacement with identical scopes and allowlist, deploy it to your bot’s configuration, confirm orders are executing normally, then delete the old key. Rotation is otherwise the control everyone agrees with and nobody does, because naive rotation means downtime and downtime on a live strategy feels worse than a theoretical risk. The fix is to make rotation boring rather than to skip it.
That overlap depends on your exchange allowing more than one active key at a time, which many do, though it is worth confirming before you plan a cutover around it. Keep both live only until you have watched the new key fill an order, then revoke the old one straight away rather than leaving it dormant. No gap, no missed fills, and no orphaned credential left behind.
A reasonable cadence for a retail trader is quarterly, plus immediately on any trigger event. Triggers include changing VPS providers, uninstalling a hosted bot platform, a vendor disclosing a breach, any malware detection on a machine that touched the key, and handing infrastructure work to a contractor.
Storage matters as much as rotation. Keys belong in environment variables, a secrets manager, or an encrypted vault — not in source code, not in a config file synced to cloud storage, not in a shared password manager note. If your bot config lives in version control, the secrets must not.
Keep a plain register of every key you have issued: which exchange, which scopes, which service holds it, when it was created. Traders who cannot answer “who has a key to this account” cannot respond to an incident. It is the difference between revoking one key and revoking everything in a panic.
Crypto exchange API key security for Australian traders specifically
Australian traders face two extra considerations on top of the controls above: counterparty choice and tax record-keeping. The exchange holding your assets controls whether allowlisting exists, whether scopes are granular, and how fast it responds when something goes wrong, which makes counterparty choice part of your security model rather than separate from it.
AUSTRAC’s expanded regime for virtual asset service providers has been phasing in across 2026. Digital currency exchange providers already on the register transitioned across automatically rather than reapplying, and update their enrolment details at their next scheduled renewal. ASIC has separately set 30 September 2026 as the date by which platforms must take a qualifying step towards licensing, with its no-action position continuing past that date while an application is determined.
Be clear about what registration is and is not. It is an AML/CTF obligation, not an endorsement, a solvency assessment or any protection of customer funds, and there is no compensation if a platform fails. For key security purposes the takeaway is narrow: prefer venues that are clearly registered and clearly documented, and keep assuming the operational risk is yours.
Tax record-keeping is the other Australian angle. A bot generates far more disposals than manual trading, and reconstructing that history after losing exchange access is miserable. Use a read-only key for your tax tooling, and export your own trade history periodically so your records do not depend on the exchange staying reachable.
Whether your crypto is taxed under the capital gains rules or as ordinary business income depends on whether you are investing or carrying on a business of trading, and that follows from your actual circumstances rather than from how you label yourself. An investor holds crypto as a CGT asset; a trading business holds it as trading stock, with proceeds assessable as ordinary income and losses deductible against other income. Trading frequently, in large volumes, or with sophisticated tooling does not by itself make you a business. Which category you fall in changes what records you must keep.
Separately, from 1 July 2027 the 50% CGT discount will no longer apply to assets held by individuals, trusts or partnerships. Under the Treasury Laws Amendment (Tax Reform No. 1) Act 2026, which received Royal Assent on 26 June 2026, it is replaced by cost base indexation — your cost base is adjusted for inflation, so only the real gain is taxed — together with a 30% minimum tax rate on that gain. This is a general CGT change affecting shares and property in the same way, not a crypto-specific measure, and gains accrued up to 30 June 2027 keep the benefit of the existing discount under transitional rules.
It does not change current treatment, but it is worth factoring into how long you retain raw trade data. Confirm your own position with the ATO or a registered tax agent.
The operational checklist
This checklist covers the twelve settings and habits that decide whether a leaked key is an inconvenience or a loss. Work through it once per exchange account, then again whenever your setup changes. It is a general starting point rather than a recommendation tailored to your situation.
- Withdrawal permission disabled on every key used by a bot or third-party service.
- Margin and derivatives scopes disabled unless the strategy actually trades them.
- Read-only keys for tax software, trackers and anything that does not place orders.
- IP allowlisting enabled and bound to a stable address you control.
- Separate keys per service, so revoking one does not take everything down.
- Secrets stored in environment variables or a vault, never in code or synced files.
- WebSockets used instead of polling wherever the exchange supports it.
- Exponential backoff implemented on throttling responses.
- A written register of every issued key, its scopes and its holder.
- Rotation scheduled quarterly and triggered immediately on any suspected exposure.
- Hardware-backed or app-based two-factor authentication on the exchange account itself, not SMS.
- Withdrawal address allowlisting enabled on the account, with a delay window if the exchange offers one.
If you act on only three of these, the first, the fourth and the twelfth are the ones that cover the scenarios which actually empty accounts. That ordering reflects how these attacks typically play out, not an assessment of your own risk.
Frequently asked questions
These are the questions Australian bot traders raise most often about permission scopes, allowlisting and rotation. Each answer below is general information, not advice about your particular account or strategy.
Can someone steal my crypto with a trade-only API key?
Not directly, but they can destroy its value. The standard technique is to use trade access across many compromised accounts to buy a thinly traded token the attacker already holds, then sell into that artificial demand. Your assets stay on the exchange; they are simply converted into something worthless.
Should I give my tax software an API key?
Yes, but a read-only one. Tax tools need your trade and transfer history and nothing more, so any request for trading permission should be refused. Review the scope selection before you save the key, because how permissions are labelled and grouped varies between venues.
What should I do if I think a key has been exposed?
Delete the key at the exchange immediately rather than editing its permissions. Then review recent orders and transfers, rotate every other key on that account, and check the device or server that held the secret for malware. Report unauthorised activity promptly, as some incident processes have short windows.
Does IP allowlisting work if my bot runs on my home computer?
Only if your address is static, and most Australian residential connections are not. The workable options are a static IP from your ISP where available, or running the bot on a VPS with a fixed address. Allowlisting a dynamic address means your bot will stop working without warning when the address changes.
How often should I rotate exchange API keys?
Quarterly is a sensible baseline for retail traders, plus immediately after any trigger event. Where your exchange allows more than one active key, you can create the replacement, cut over, verify execution and delete the old key with no downtime.
Is it safer to run my own bot than to use a hosted platform?
Self-hosting removes the vendor from your threat model but makes you responsible for server hardening, dependency hygiene and patching. Hosted platforms handle that for you while requiring you to trust their security practices. Neither is categorically safer, which is precisely why withdrawal permission should stay disabled either way.
