Bloom trading bot: 9,408 SOL drained, what to watch now

The Telegram trading bot Bloom reported an outflow of 9,408 SOL on October 26, 2026. On Bloom's own assessment, nine users holding 49 wallet addresses are affected. The provider points to a remote code execution flaw in a third-party module as the point of entry, has promised full reimbursement and has shut down all systems as a precaution.

For you as the user of a trading bot, the key detail is not the sum but the design behind it: with Bloom it is the provider who creates the private key, not you. That is precisely what separates a bot wallet from a wallet you control yourself, and it is precisely what decides whose problem an incident like this ultimately is.

Bloom drain: 9,408 SOL from 49 addresses held by nine users

The quantity is the same in both reports examined: 9,408 SOL. The figures for the value diverge, because they were calculated at different moments. Bloom itself puts the damage at around $947,000, according to Bitcoin.com News, while an initial analysis of the transactions arrived at roughly $954,000. A range of $947,000 to $954,000 therefore stands, and anyone turning that into a round million is calculating loosely.

The number of victims also repays a close look. The first reports spoke of 49 victims. Bloom has since placed that in context: there are nine users who between them controlled 49 addresses. Cryptobriefing cites a range of 48 to 49 affected addresses. The largest single outflow came to 1,636 SOL, or around $166,000, as measured by the monitoring account Onchain Lens and quoted by news.bitcoin.com. Individual traders affected reported losses of up to $80,000.

A monitoring service called Onchain Alert considers the final sum possibly higher, because the funds were pooled in a suspected drainer wallet. That is an assessment, not an established figure, and it stands here as such.

Remote code execution: Bloom points to a third-party module

Bloom traces the incident to a complex RCE flaw. RCE stands for remote code execution, meaning a weakness through which an attacker can run their own program code on someone else's server. Whoever has that ability operates on the server with the same rights as the software running there.

Where the flaw came from changes nothing for those affected

The fact that the weakness sat in a bought-in module rather than in Bloom's own code makes no difference to those who lost funds. Technically, a service executes everything that runs in its name, third-party libraries included. Which point of access was broken open exactly, Bloom had not disclosed as at the time of this analysis. Cryptobriefing notes explicitly that no cause has been confirmed so far and that affected users suspect the weakness in the service itself, without that having been verified.

Custodial wallet: with Telegram trading bots the provider creates the key

Here lies the part of the story that reaches beyond this single incident. A Telegram trading bot is meant to be fast. What makes it fast is that it can sign orders without asking first, and it can only sign if the private key is reachable where the bot runs. Cryptobriefing therefore describes Bloom as a service that creates its users' private keys itself, and names the known risks of that design: keys held server-side, and hijacked Telegram accounts.

A custodial wallet is a wallet in which a third party holds the key and disposes of it on your behalf. That is the case at an exchange and equally at a trading bot. What you hold then is a claim against the provider, not direct access to the coins. Which bot providers hold keys in which way, and what they cost, is set side by side in our overview of crypto trading bots.

No private keys leaked: the open question in the account

According to the news.bitcoin.com report of October 26, 2026, Bloom stated on X that no private keys had leaked, that unaffected wallets were safe and that everyone who lost funds would be reimbursed in full.

That leaves one question open, and the report poses it itself: if no key leaked, how did the attacker come by the authority to move the funds? A transfer on the Solana blockchain is executed only if it is validly signed. Both statements can be reconciled if the key never left the server but was usable there by the attacker. Bloom had not resolved this as at the time of this analysis, and without disclosure the gap in the account remains. What actually happened cannot be inferred from it.

For you this has one sober consequence. The assurance that unaffected wallets are safe rests on the same investigation that has not yet been able to name the cause. That is a statement by the provider, not a verified finding.

SOL flowed out, USDC stayed put

The attacker did not take everything that sat in the addresses. According to the initial analyses summarised by Cryptobriefing, the outflow targeted SOL almost exclusively, while USDC holdings in the same wallets went untouched.

That selection is revealing. Anyone working under time pressure takes the asset that can be moved on fastest and with the least friction. A stablecoin from a named issuer can be frozen on request; SOL cannot. The stablecoin holdings being left behind therefore points to a deliberate decision by the attacker rather than to carelessness.

Reimbursement in full: Bloom has named no deadline

Bloom has pledged to carry the entire loss, and to pay it to wallets that those affected nominate themselves. No deadline for that is on the table. news.bitcoin.com notes that no date has been set for the reimbursement, nor any point at which the services will come back.

In parallel, the provider is tracing the funds, examining options for freezing and recovery, and trying to identify the attacker. Announcements of this kind are customary in incidents of this size. For the time being, the only reliable thing about the pledge is that it was given.

MiCA and custody: what applies to third-party keys in Germany

Anyone who holds and administers crypto assets for others in the European Union is thereby providing a crypto-asset service within the meaning of the MiCA regulation, and needs authorisation for it. In Germany the competent authority is BaFin, and the authorised providers are listed in a public register maintained by the European securities authority ESMA. Whether a service you use is entered there is something you can check yourself; this article makes no finding on the point.

The second part matters just as much: authorisation is not deposit protection. The 100,000 euros that are protected per customer at a bank do not apply to crypto assets, not even at an authorised custodian. A reimbursement pledge like Bloom's is therefore a voluntary act by the company and not a claim arising from a protection scheme.

Which questions count before you switch a bot on

Three points are settled before the first deposit, not after it: who creates the key, where it sits, and what sum is reachable by the bot at any given moment. On the third point you have your own hand on the lever, regardless of what a provider pledges.

Self-custody instead of a bot wallet: the difference in key control

Self-custody means the private key sits with you alone and no third party's software can use it. A hardware wallet enforces that by holding the key in a chip that never releases it; signing happens on the device, after confirmation on the device. Which models implement that in which way, and what they cost, is set out in our hardware wallet hub comparison.

This design is slower than a bot, and that is its purpose. A bot that signs without confirmation can buy and sell within seconds; but the same mechanism also works for anyone who gains access to the executing environment. The decision therefore comes down to a trade-off between speed and control over the key, and it need not be the same for your entire balance.

A split in two is the common approach. The trading wallet holds the amount the bot is meant to move, and nothing else. The rest sits on a wallet that no provider's software can reach. In Bloom's case that separation would not have prevented the outflow, but it would have capped the amount that was reachable in the first place. That is the part of the risk the user alone disposes of.

Bloom Manager and the Chrome extension: a fresh login after the restart

For the period after the relaunch, Bloom has issued a notice that concerns every user, including those who were not affected. As soon as the services are back, all users will have to log in again to Bloom Manager and to the Chrome extension. Those affected are to contact support and move any remaining assets to newly created wallets; that is how news.bitcoin.com relays the provider's instructions.

This phase is the moment when phishing tends to start up. A prompt to log in again is a template for attackers, because it is genuine. Any message pressing you to log in or to enter a recovery phrase is therefore something you treat as an attempted fraud until you have verified the address independently. After delivery addresses leaked at a wallet manufacturer in October, the same scheme was already under way.

Bloom drain: without your own keys, only the reimbursement pledge remains

Three steps follow from this incident, and they apply regardless of whether you use Bloom:

1. Cap the balance on bot wallets. Leave only the amount reachable that the bot is meant to move over the next few days. Which provider holds keys in which way is shown in our comparison of trading bots.
2. Bring the rest under your own key control. A device that does not release the key shuts off the route that stayed open here. The models and their costs are set out in the hardware wallet comparison.
3. Choose the trading venue by its custody arrangements. Anyone trading without a bot needs a provider with traceable custody and authorisation; the candidates are listed among the regulated crypto exchanges.

(As of October 27, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)