On Monday, October 26, 2026, users of BloomTrading, a Telegram-based crypto trading bot, reported that SOL had been drained from their bot wallets. Blockchain investigators estimated that about 9,408 SOL, roughly $954,000, reached a single suspected receiving address. The cause has not been confirmed, and the company says it is still investigating. Whatever the root cause turns out to be, the incident is a sharp reminder of one operational question every automated trader should be able to answer in a sentence: if the tool I use were compromised tonight, what could the attacker do with the access I gave it? This crypto trading bot key checklist turns that question into five checks.
This article uses public reporting about a third-party service as context. Gimmer is not affiliated with BloomTrading, does not integrate it, and nothing here describes a Gimmer incident or claims that any tool, including Gimmer, is immune to compromise. It is not a trading signal or a recommendation about any bot, wallet, exchange or asset. If you use BloomTrading, follow the company’s own announcements.
What happened
According to crypto.news, which published its report at 06:14 UTC on October 26, the on-chain monitor Onchain Lens linked the outflows to 49 suspected victim wallets, with about 9,408 SOL reaching one suspected address. The largest single reported loss was 1,636 SOL. Some users reported that USDC in the same wallets was left untouched while SOL was moved, although that observation has not been confirmed across every wallet. In a statement posted on X on October 26, BloomTrading said it would fully compensate nine affected wallets by sending replacement funds to new addresses chosen by their owners, and that it was “still actively investigating the root cause.”
Crypto Briefing reported the same figure and added context about the product: the bot generates the private keys for its users’ wallets, so the platform, not the trader, holds the master credentials. The company has said it is examining whether a third-party service provider was compromised, but no vulnerability, attacker or root cause has been confirmed. Reports also say some services were paused during the investigation and that users were asked to move remaining funds to newly generated wallets. The victim counts in the reports are not reconciled (nine wallets in the company’s statement, 48 to 49 in investigators’ estimates), and neither the refund schedule nor the final loss figure has been published.
Three different things are easy to blur together in an incident like this:
- Who holds the credential: a key you created and stored yourself, or one a service generated and keeps on its servers.
- What the credential can do: a wallet private key can move everything the wallet holds; a scoped exchange API key can be limited to trading.
- Where the credential works: from anywhere on the internet, or only from a known address and a known application.
The size of a loss after a compromise is decided mostly by the second and third points, and those are the parts an operator can set in advance.
Common mistakes with trading bot credentials
Bot incidents tend to expose the same handful of habits:
- Convenience becomes full authority: a bot asks for a private key or a key with every permission because it is easier to set up, and the operator grants it without asking what the bot actually needs.
- One key serves many tools: the same API key is pasted into several bots, dashboards and scripts, so a breach at any one of them exposes all of them, and nobody can tell which tool leaked it.
- Withdrawals are left on “just in case”: a trading tool rarely needs to move funds off an exchange, yet withdrawal permission is enabled because it was the default or seemed harmless.
- A refund promise replaces a review: the operator waits for compensation and keeps using the same keys. Disconnecting an app does not invalidate a key that may already have been copied.
A five-check crypto trading bot key checklist
Fill in one row per tool that holds any credential for your funds: bots, dashboards, tax tools and scripts. Each check has a question and evidence you can keep.
| Check | Question to answer | Evidence to keep |
|---|---|---|
| 1. Holder | Who holds this credential: you, on your own machine, or the service, on its servers? | The tool name, where the credential is stored and who generated it. |
| 2. Scope | What can the credential do? Can it trade only, or can it also withdraw or transfer? | A note of the permissions shown at the exchange, with the date you checked them. |
| 3. Origin | Where can it be used from? Is it restricted to a known IP address? | The IP allowlist, or a note that none is set and why. |
| 4. Isolation | Is this key used by exactly one tool, with a label that says which one? | The key label, the tool that uses it and the date it was created. |
| 5. Revocation | If this tool were compromised tonight, could you revoke the key and know what to rebuild? | The exchange page where the key is revoked, plus a written replacement procedure. |
A row where the holder is a third party and the scope includes withdrawals is the row to fix first, because that combination lets a single compromise move funds.
Use Gimmer’s exchange connection guide to narrow the key
Gimmer’s Connect an exchange guide opens with the principle this incident illustrates: connect an exchange “with the narrowest useful permissions” and keep withdrawal permission disabled. The guide is marked security-sensitive, and each step maps to a row of the checklist.
Keep the credential on your machine
Gimmer is a desktop workspace, and the guide tells you to enter credentials “directly in the local desktop app” and not to paste them into the public website. That answers the holder check: you create the API key at the exchange, and you type it into the app on your own computer. Keep that computer patched; the earlier software update checklist covers taking packages only from the official source.
Grant trading access only
The guide’s preparation steps are explicit: turn on strong multi-factor authentication at the exchange before creating API access, enable spot and, only when required, margin permissions, and “Never enable withdrawals for Gimmer.” A key with no withdrawal permission is still sensitive, because it can place trades, but it removes the most direct way for an attacker to move funds off the exchange with it.
Restrict where the key works
The guide recommends applying IP restrictions when practical, since “a stable egress IP can further limit where the key is usable.” If your address changes often, note that in the origin column rather than skipping the check.
Use a dedicated, labelled key
The guide asks for a dedicated API key with a clear label such as Gimmer, and says to avoid sharing the key with another bot. That single habit makes the isolation check possible: if one tool is breached, you revoke one key and you know exactly which connection to rebuild.
Validate, then revoke on exposure
After saving the connection in Exchanges, run the available health or validation action, because “a saved credential is not necessarily a working credential.” The guide’s failure table separates Authentication failed, Permission denied, Insufficient balance, Minimum order failure and Rate limit or unavailable; a Permission denied result after you remove a permission is evidence the scope change took effect. Finally, if a key or secret appears in a screenshot, log, chat, repository or support message, the guide says to revoke it at the exchange and create a new restricted key. The API error guide explains how to tell these signals apart, and the AI agent controls checklist applies the same limit-the-authority idea to automated decisions.
A short example: one alert, five checks
Consider a synthetic trader who uses two tools: a hosted chat bot for occasional token trades, and Gimmer for a small strategy running in simulation against an exchange connection.
- They read the October 26 reports and note the facts as stated: the estimated amount, the unconfirmed cause and the company’s refund pledge. They do not change any strategy setting because of it.
- For the hosted bot, the holder check shows that the service generated and holds the wallet key. They move the balance they no longer want exposed to a wallet with a newly generated key that the service never saw, and record the date.
- For the exchange connection, the scope check shows trading permission only, with withdrawals disabled. The origin check shows no IP restriction, so they add their always-on host’s fixed address to the allowlist.
- The isolation check reveals that a portfolio dashboard uses the same key. They revoke it, create two new keys labelled by tool, enter the Gimmer one in the local desktop app and run the validation action.
- They confirm that balances and markets load, then watch runtime activity until the next expected candle evaluation appears in simulation before marking the review complete.
The outcome is a smaller blast radius and a written record, not a guarantee that no tool will ever be compromised. The example is not a recommendation to use any particular bot, wallet, exchange or strategy.
What this key checklist cannot do
- It cannot tell you whether a third-party service is secure, or detect a compromise before it is disclosed.
- It cannot protect funds held under a private key that a service already controls; only moving those funds to a key the service never saw changes that.
- A trading-only key can still place unwanted trades if it is stolen; scope reduces the damage, it does not remove it.
- IP restrictions and permission settings depend on what each exchange offers, and Gimmer cannot enforce them on the exchange’s side.
- It does not replace monitoring: check balances and open orders directly at the exchange, not only in any application.
Trading digital assets involves substantial risk. Backtests and simulations do not guarantee future results, and no permission setting or risk control guarantees that funds cannot be lost.
Frequently asked questions
Does the BloomTrading incident affect Gimmer?
No connection has been reported. Gimmer does not integrate BloomTrading, and the cause of the drain has not been confirmed. The checklist applies to any tool that holds credentials for your funds, Gimmer included.
Is a trading-only API key safe to share with any bot?
No. It is less dangerous than a key with withdrawal permission, but it can still trade. Gimmer’s guide asks for a dedicated key used by one tool, entered only in the local desktop app.
Does Gimmer support help ever need my secret or private key?
No. A legitimate support interaction should not require your seed phrase, private key, complete API secret or account password. If a secret has been shared anywhere, revoke it and create a new restricted key.
Decide the blast radius before the breach
The BloomTrading reports are still developing. The question they raise is lasting: what can each of your tools do with the access you gave it? Answer it before the next incident.
Next step: open Gimmer’s Connect an exchange guide, fill in the five-check table for every tool that holds a credential, and revoke any key that is shared, unlabelled or able to withdraw.
— The Gimmer Team