An attacker emptied 48 wallets belonging to nine users of the Bloom trading bot in 94 seconds on Monday 26 October, taking 9,408 SOL, according to an on-chain investigation by Bitquery. Bitquery values the haul at about $953,000, using the SOL price during the drain (around $101.3). Only SOL was swept; the stablecoins in the same wallets were left for later.
The Bloom trading bot hack comes with two accounts that do not match. Bloom, a Telegram-based bot for Solana and EVM chains, says no private keys were compromised and blames a remote code execution (RCE) flaw in a third-party software module. Bitquery’s reading of the chain is that every drain was a plain SOL transfer signed only by the drained wallet’s own key. Nobody has published proof of the cause. Bloom has promised full refunds but has given no date.
The counts differ slightly. Bloom puts the loss at about 9,408 SOL, or $947,000, taken from “49 wallet addresses belonging to 9 users”, in a statement on X; early on-chain reports cited about $954,000, Bitcoin.com News noted. Bitquery counts 48 drained wallets because one of the 49 addresses has never made a transaction, so there was nothing in it to take. The dollar figures differ mainly by the SOL price each one used.
The Bloom trading bot hack on-chain: 94 seconds, 48 wallets, nine traders
Bitquery rebuilt the night minute by minute. At about 00:59 UTC on 26 October, two attempts on the largest wallet of the first trader failed. At 01:00:28 UTC a 0.01 SOL test transfer reached a fresh address, 7kY8qx8MqJ7Rz2vMhgHETdZLHcTp1oM78AA9dmE9p8BQ, the first SOL it ever received. Nine more tiny tests followed within two minutes, one per trader, a few seconds apart.
Then the sweep. The first full drain came at 01:03:07 UTC. The biggest single transfer, 1,636 SOL (about $166,000), went through at 01:03:50 UTC; the on-chain tracker Onchain Lens flagged it, Bitcoin.com News reported. The last drain landed at 01:04:41 UTC.
Each drain was a simple SOL transfer, Bitquery says, signed only by the key of the wallet being emptied. No token approval, no smart contract, no co-signer. The script went trader by trader in a fixed order, largest wallet first, paid the same 0.000105 SOL fee on every transaction (a 0.0001 SOL priority tip included) and left a sliver of SOL, about 0.0014, in each wallet. Bitquery reads this as a scripted attack by someone who already had the wallet list and could sign for those wallets.
At 04:30:56 UTC, three and a half hours after the drain, the whole 9,408.21 SOL moved in one transfer to a holding wallet, 6nYyCzJJzErbmfxvXqzbAqwoBzNvXUiwr15KCkcgmoe9. Bloom’s first post on X came at about 04:37 UTC, according to Bitquery’s timeline.
The USDC the attacker came back for
About $56,853 of USDC sat in the 48 wallets at the time of the drain, Bitquery found, most of it (about $49,041) in one wallet of the first trader. At 01:08:51 UTC the attacker tried to move it, and failed: the wallet no longer had enough SOL to pay the fee. At 01:28:43 UTC the attacker sent it 0.02 SOL for fees. The owner was faster and moved 48,550 USDC out at 01:30:19 UTC. When the attacker’s test transfer went through at 01:46:03 UTC, about 0.52 USDC was left.
Owners moved about $52,035 of USDC to safety that night. Some $4,818 was still in the drained wallets when Bitquery read them at 06:33 UTC.
Losses per trader: from 1,864 SOL down to 650 SOL
The nine victims lost between 650 and 1,864 SOL each. The median loss per wallet was about 89 SOL, or roughly $9,000. Few victims and large balances: that sets Bloom apart from the bot incidents of September.
| Trader (Bitquery numbering) | Wallets drained | SOL drained | Value at the time |
|---|---|---|---|
| Trader 1 | 5 | 1,864 | $189,000 |
| Trader 2 | 4 | 1,146 | $116,000 |
| Trader 3 | 6 | 1,309 | $133,000 |
| Trader 4 | 1 | 1,040 | $105,000 |
| Trader 5 | 1 | 1,022 | $103,000 |
| Trader 6 | 5 | 865 | $88,000 |
| Trader 7 | 7 | 771 | $78,000 |
| Trader 8 | 12 | 650 | $66,000 |
| Trader 9 | 7 | 742 | $75,000 |
Bitquery adds a caveat. The grouping of wallets into traders is firm for seven of the nine; for traders 3 and 7 it rests mainly on the order in which the wallets were drained.
Bloom blames a third-party module and says no private keys were compromised
Bloom’s fuller statement went up on X at 09:12 UTC on 26 October, about eight hours after the drain. “No private keys were accessed or compromised, and we have ruled out broader exposure of users’ wallets,” the company wrote. It says the attack “exploited a third-party module through a complex Remote Code Execution (RCE) vulnerability” and that it has “identified the exact attack vector”. It has not named the module, the vendor or the vector.
On refunds, Bloom says it “will fully reimburse 100% of the stolen funds directly to secure wallets designated by the affected users”. Its earlier post, at about 04:37 UTC, already promised to “fully reimburse all funds lost by the 9 affected wallets”, Bitquery reports. No date has been set, and nothing on-chain showed a refund by 27 October.
All Bloom systems were taken offline “as a precautionary security measure”, and users will have to log in again to Bloom Manager and the Chrome extension when service resumes, Bitcoin.com News reports. Bloom says it is tracing the funds, looking at freezing and recovery options and trying to identify the attacker, and it tells affected users to move what they have left to newly generated wallets.
The team says it has been developing software since 2018 and operating in crypto since 2021. Coindaro found no published figure for its number of users or its trading volume; its X account had about 26,500 followers on 27 October.
Why the two accounts conflict
Bitquery does not take sides on the cause. It reports that Bloom first said it was checking whether “a third-party provider may have been compromised”, and it treats the cause as unconfirmed.
Its trace still sits badly with the “no keys” line. Bloom’s bot signs trades on its own servers and keeps the private key to each wallet used with it, Bitquery explains. A plain SOL transfer on Solana needs one thing: a valid signature from the wallet’s key. If each drain was signed by that key, whoever ran the script could produce those signatures. That could mean the keys were copied, or that the attacker made Bloom’s own systems sign for them; an RCE flaw on a server fits the second reading. Bitquery adds a third possibility, malware on each trader’s computer or a leak of keys the traders had exported. None has been shown.
The difference matters to users. If keys were copied, every wallet whose key ever lived on Bloom’s servers stays exposed until its funds move. If the attacker only borrowed Bloom’s signing system for 94 seconds, the risk ends once that system is fixed. Bloom’s advice to move funds to new wallets reads like the first case. For how one key controls a wallet, see our guide to private and public keys.
Where the 9,408 SOL sit now: the first 20 SOL have moved
At 07:34 UTC on 26 October, the last transfer Bitquery read, the holding wallet had sent nothing out, and no exchange, bridge or mixer had touched either attacker wallet.
That changed on 27 October. Coindaro read the holding wallet’s history on a public Solana mainnet node at 11:55 UTC that day. It had sent two transfers of 10 SOL each, at 06:40:55 UTC and 11:42:44 UTC, to two new addresses (GfHDgSHQwBw5ssuMRdfw9JLKWzQAvnwJ7ajk7SuzdeFr and HqCbwhMAJgf3EMabx3Kty8mCo9E2ZjqoHcNDbonPP9Am). Both were emptied within hours through a string of smaller transfers, several of about 1 SOL each, to other addresses, which Coindaro did not trace further. The holding wallet’s balance stood at 9,388.21 SOL at 11:55 UTC.
The rest of its incoming traffic is dust: transfers of 0.0001 SOL or less from addresses that start with the same characters as the attacker’s, which is what Bitquery describes as address poisoning, look-alike addresses meant to be copied by mistake. Our guide to poisoned addresses and fake airdrops explains the trick.
Because the attacker holds SOL, the dollar value moves with the market. SOL traded near $100 at 11:32 UTC on 27 October, down 1.34% over 24 hours, which puts the 9,388 SOL left in the holding wallet at about $939,000.
Half of the drained wallets had gone quiet
Many victims were not active Bloom users. All 48 wallets had paid a Bloom fee at least once, but 24 had paid none in the 30 days before the attack, and five had last traded through Bloom between January and May 2025, according to Bitquery.
A key stored on a bot’s servers does not expire when you stop trading. As long as the wallet holds funds, whoever gets signing access can empty it, whether its owner logged in last week or last year.
Trading-bot hacks before Bloom, from Maestro to TradeWiz
Two Ethereum bots were hit a week apart in October 2023: Maestro on 24 October and Unibot on 31 October, for about $1.1 million together, according to CertiK’s analysis. Both had router contracts that let an outsider call transferFrom on tokens users had approved. Approvals were the way in, which is not what happened at Bloom.
On Solana, the Telegram bot Solareum lost more than 2,800 SOL (about $520,000) from over 300 users in late March 2024 and announced on 31 March that it would wind down, Cointelegraph reported. The report mentions no refund. BONKbot, at first suspected, said it was safe and that the exploit hit “another Solana app”.
Banana Gun went the other way. Its users reported unauthorised transfers on 19 September 2024. The team’s post-mortem, reported on 25 September, put losses at $3 million from 11 users, pointed to a suspected flaw in a Telegram message oracle, which it patched, and promised that “all impacted users will be fully refunded from the Banana Gun treasury”, Cointelegraph reported.
Bitquery also lists two September 2026 cases that Coindaro has not checked independently. LootBot, an Ethereum airdrop bot on Telegram, lost about $627,000 from some 2,400 wallets on 7 and 8 September, with a median loss of about $26. TradeWiz, on Solana, lost about $459,000 from more than 20,000 wallets on 30 September, a median of 63 cents. Those were wide nets with small sums per victim. Bloom is the opposite: nine people, large balances, taken in order.
Telegram and web trading bots: who holds your keys
Most Telegram and browser-based trading bots are custodial in practice. When you sign up, the bot creates a wallet for you and keeps its private key on its servers, so it can sign trades in a fraction of a second without asking. That speed is the product. It also means the bot, and anyone who breaks into it or into one of its suppliers, can move your funds. Our guide to crypto wallets and custody sets out the difference between a wallet you control and one held for you.
Some habits limit the damage when a bot is breached:
- Keep in a bot wallet only what you are trading with now, and send profits back to a wallet whose key never left your device.
- Empty bot wallets you no longer use: 24 of the 48 wallets drained from Bloom had paid no fee for at least a month.
- After an incident at your bot, move remaining funds to a freshly generated wallet rather than reusing the old address.
- Treat exporting a bot wallet’s key into other apps as a new risk, not a backup: the key then lives in two places.
- Check the full destination address before sending anything after a hack; look-alike addresses are already circling this one.
Victims who hope to see funds come back can read what actually works to recover stolen crypto. Credentials kept on someone else’s servers were also the weak point the day before in the GMO Internet cyberattack in Japan.
What is still unknown
Who the attacker is, and how they got the ability to sign for 48 wallets. Bloom has not named the third-party module or vendor behind the RCE flaw it describes, and nobody has published a technical post-mortem. Until one is out, “no private keys were compromised” and Bitquery’s signature pattern stand side by side.
Why these nine traders were picked is also open; their large balances and the many dormant wallets are the only clues. The refund has no date, and Bloom has not said when its systems come back. The next signals will be on-chain: where the first 20 SOL out of 6nYyCzJJzErbmfxvXqzbAqwoBzNvXUiwr15KCkcgmoe9 end up, whether the rest follows, and the first refund transfer from Bloom to the victims.