Connecting a trading bot, journal or analytics tool to an account is mostly a permissions decision. The questions are what the tool can read, what it can do, what it can move, and how quickly you can take that access back. This guide works through least-privilege API keys, separating signing wallets from storage wallets, login and device protection, signature discipline and a written recovery plan. It describes general practice; the exact controls differ by venue, so check each one’s current documentation before relying on a feature.
Start with the job, not the key
Access usually falls into three tiers. Read covers balances, positions and trade history. Trade covers placing and cancelling orders. Move funds covers withdrawals and transfers. Write down which tier the tool’s job actually requires before you create anything.
A trade journal or tax export generally needs read access only. A bot that executes a tested rule needs trade access, and should first have passed the evidence steps in the algorithmic trading research workflow. Very few legitimate tools need to move funds. Paper practice needs no exchange key at all, which is one reason to stay there until the paper-to-live differences are understood.
SuperQuant is a research tool. It uses synthetic hourly data for its included examples and does not place live orders, so researching a rule there does not involve granting it trading permission on an exchange account, and no step of that research calls for a recovery phrase.
Scope every API key
When a venue issues API keys, treat each key as a standing instruction that works without you present. A few habits keep that instruction narrow:
- Leave withdrawal and transfer permission off unless the specific job requires it. A leaked trade-only key can still cause losses through bad orders, but it is a smaller problem than one that can send funds out.
- Use an IP allowlist where the venue offers one, so a copied key fails when used from an unknown address.
- Issue one key per tool, with a clear name. Revoking one key then does not break the others, and account logs can show which tool acted.
- Set an expiry or a review date. Unused keys are easy to forget and still valid.
- Store the secret like a password. Keep it in a secrets manager or local environment configuration, never in a chat message, screenshot, shared document or code repository.
A key usually authenticates requests on its own, without the account’s login prompt or second factor. That is why its scope matters more than the strength of the login that created it.
Separate signing wallets from storage wallets
On-chain venues often use wallet signatures in place of API keys. Hyperliquid’s exchange-endpoint documentation describes approving an API wallet, which it says is sometimes called an agent wallet. The page states that an account can have one unnamed approved wallet and up to three named ones, with additional named agents allowed per subaccount, and that a custom expiration can be set at most 180 days in the future. It also says subaccounts and vaults have no private keys of their own; actions on their behalf are signed by the master account. It describes one asset-send action that an agent can sign, with the destination required to match the source address.
That page does not give a complete list of what an approved agent cannot do. Read the venue’s current API wallet documentation before treating that separation as a security boundary.
The general principle holds across venues: the key on the machine running automation should not be the key that controls long-term holdings. Keep storage in a wallet that never connects to bots or experimental sites, and fund the trading account only with what that strategy is meant to risk. The trade-offs between hardware and software wallets explain how key exposure differs between the two, and what neither one removes.
Protect the login and the device
Account login is a separate layer from API access, and it still matters: whoever controls the login can usually create new keys. Where a venue offers them, passkeys or an authenticator app are generally stronger than codes sent by text message. The guide to passkeys and two-factor options compares the choices and the recovery steps each one needs.
The device is the next layer. A browser profile used only for trading, few or no unnecessary extensions, remote-access software removed when it is not needed, and prompt operating-system updates all reduce exposure. The checklist for a safer everyday crypto device covers these steps in more detail.
Never paste a recovery phrase, and read what you sign
No exchange, bot, support agent or research tool needs your recovery phrase. Anyone who has it can generally control the wallet it restores; the explainer on what recovery phrases control describes why it is so sensitive. A request to “verify” or “sync” a wallet by typing those words is a reason to stop.
Signatures deserve the same care. A wallet prompt that shows unreadable data, an unfamiliar contract or a spending permission unrelated to the task you started is a request to approve something you cannot see. The guide to blind signing and message signatures explains why a signature with no gas fee can still carry consequences.
A CFTC investor alert on fraudulent digital asset trading websites lists warning signs that often surround fake bots: guaranteed returns with little or no risk, complicated jargon, unsolicited contact, pressure to act quickly, and requests to pay additional costs, such as purported taxes, to withdraw fake profits. It advises verifying statements, researching the people and firms involved, and checking registration before paying.
Write the recovery plan before you need it
A recovery plan is a short document you can follow under stress. It lists every key, agent and wallet, what each can do, and exactly how to revoke it. A fictional inventory might look like this:
| Item (fictional) | Job | Permissions | Review | How to revoke |
|---|---|---|---|---|
| Key “journal-ro” | Trade history export | Read only, IP-restricted | Monthly | Venue API settings |
| Agent “bot-sub1” | Orders for one subaccount | Trade; transfers not relied on | 90-day expiry | Venue API wallet page |
| Storage wallet | Long-term holdings | Hardware-signed, never connected to bots | Quarterly check | Recovery phrase offline |
Then write the incident steps in order: revoke keys and agents, cancel open orders, change the login password and second factor, and, if a recovery phrase may be exposed, move holdings to a newly created wallet. Keep evidence such as timestamps and transaction identifiers without sharing secrets, and reach support only through an address you bookmarked yourself. The CFTC alert gives reporting routes to the SEC and CFTC for anyone who invested in a suspected fraud.
Keep learning
The wallet confidence learning path builds these habits step by step, and the practical wallet safety system ties device, recovery and signing checks together. If alerts are your entry point, the signal bot workflow keeps a human decision between a message and any order. This is educational research context, not investment advice.