Users of Bloom, a Telegram-based cryptocurrency trading bot, lost approximately 9,408.23 SOL worth $953,000 when 48 Solana wallets were drained in a coordinated 94-second operation on October 26. The affected addresses were associated with nine traders, according to an on-chain investigation by Bitquery. Bloom has pledged full reimbursement, but the method by which the attacker gained signing control remains unresolved.
The most important finding is how the money moved. Investigators found that each draining transfer was authorized with the affected wallet’s own signing key, without a smart-contract exploit, approval abuse or separate co-signer. The blockchain establishes that signing authority was used; it cannot identify who obtained that authority, whether private keys were copied or where any possible exposure occurred.
The operation also reached wallets that had not traded through Bloom for more than a year. That raises a more consequential custody question than the immediate loss figure: when a trading bot has handled a wallet key, does stopping use of the bot actually end the associated risk?
How Did 48 Bloom Wallets Lose 9,408 SOL in 94 Seconds?
The theft unfolded early Monday, with initial tests around 01:00 UTC, or 04:00 in Cairo. In its October 26 on-chain reconstruction, Bitquery identified an initial small transfer from a victim wallet to a newly created collecting address, followed by small tests involving other traders. The first complete wallet drain occurred at 01:03:07 UTC. The last was recorded at 01:04:41 UTC, a 94-second interval.
After testing one wallet linked to each trader, the operation worked through the wallets grouped by owner, generally taking larger SOL balances before smaller ones. Eight of the nine groups followed that descending-balance order precisely. The transfers shared standardized fee settings and left similarly small residual SOL balances. Together, the timing and repeated transaction structure are consistent with a scripted sweep rather than unrelated users making spontaneous withdrawals.
The largest individual wallet lost approximately 1,636 SOL, worth about $166,000 at the incident’s estimated price. Six wallets accounted for roughly 61% of the stolen SOL, indicating that the theft was concentrated in high-value addresses rather than a uniform sweep of every Bloom user.
Early monitoring accounts sometimes described 49 compromised wallets. Bitquery separated 48 source wallets that lost SOL in the drain from other addresses sending small dust transfers to the collecting address. Likewise, 48 affected wallets do not mean 48 distinct people: its transaction clustering associates the wallets with nine traders, matching Bloom’s reported count of affected users. Bitquery described some owner-level clustering as stronger than others, so its mapping remains a research finding rather than an identity registry.
At an estimated SOL price of roughly $101.30 during the attack, the reported 9,408.23 SOL outflow corresponds to approximately $953,000. That is a historical incident valuation, not a claim about the amount the cryptocurrency would fetch today.
Why Do the Signatures Point to Key Access Rather Than an Exploited Contract?
For every draining transaction, investigators found a straightforward native SOL transfer authorized by the sending wallet’s key. A contract vulnerability could allow unexpected behavior inside a program, while a malicious token approval could give another address specific spending rights. Neither mechanism explains the transfers identified here: the transaction authorization came from the wallet’s normal signing authority.
That does not prove Bloom’s own servers were breached. A bot that signs transactions on behalf of traders needs a mechanism for accessing or exercising key material. If a central key store or an outside signing service were compromised, several customer wallets could become reachable at once. But copied key exports, a compromised user device, or another route to the same signing authority could generate transfers that look identical on-chain. The evidence proves the use of credentials or signing authority, not the original intrusion point.
The dormant wallets sharpen this distinction. Bitquery found that 24 of the 48 addresses had not paid Bloom trading fees within the preceding month. Five had last been used with the bot in the first half of 2025. A signing key does not expire just because an app is no longer used; if the key remains valid and a balance is later deposited, someone with access to the secret can still move it.
The investigators also noted that more than 6,000 wallets had paid Bloom fees during the previous month. The incident therefore does not establish that every wallet connected to the service was exposed, or that an attacker accessed an entire user-key database. A relatively narrow selection of high-value wallets could reflect targeted data access, partial compromise or prior acquisition of a smaller collection of keys. None has yet been demonstrated conclusively.
This risk differs from the familiar wallet-drainer scenario in which a user signs a malicious token allowance. As explained in DaveFinances’ guide to wallet approvals and phishing, revoking an allowance can address the authorization granted to a spender, but cannot turn a key already controlled by someone else into a secret again. Recovery requires a new, independently generated signing key.
What Happened to the $56,853 in USDC Left Behind?
The attacker concentrated on native SOL despite other assets in the wallets. Bitquery calculated that approximately $56,853 of USDC remained during the original drain, alongside other tokens. The presence of those balances was not evidence that the attacker lacked access to the wallets; a script configured to transfer SOL could simply leave non-SOL assets untouched.
Investigators subsequently observed an attempted USDC transfer from one wallet holding about $49,041. The effort initially failed because the wallet lacked sufficient SOL for the fee. The attacker later provided a small SOL top-up. Yet the owner moved the USDC to another address 96 seconds after that top-up arrived, before the attacker’s subsequent attempt could capture the funds. Bitquery’s transaction clustering linked the receiving address to previous funding activity involving that trader, although blockchain data alone does not prove personal identity.
The $49,041 should not be added to the $953,000 stolen figure as a second loss. It was an attempted theft that investigators say failed. Nor should the $56,853 in USDC be described as already seized, frozen or recovered by authorities: these assets had initially stayed in the user wallets and were subsequently moved by their owners. By the morning of October 26, Bitquery found fewer than $5,000 in USDC remained across the 48 affected wallets.
The incident demonstrates the practical value of rapid containment. Owners still able to sign with their wallets may have only a narrow opportunity to transfer surviving assets before an adversary exercises the same authority. Once a key is suspected to be exposed, simply unplugging a Telegram bot or revoking contract allowances may not prevent further signing.
Where Did the Stolen SOL Go, and Has Bloom Reimbursed Users?
Bitquery traced the stolen SOL first to the collecting address 7kY8qx8MqJ7Rz2vMhgHETdZLHcTp1oM78AA9dmE9p8BQ. At approximately 04:30:56 UTC on October 26, the funds moved to another newly created address, 6nYyCzJJzErbmfxvXqzbAqwoBzNvXUiwr15KCkcgmoe9.
At the investigation’s final transaction-review cutoff, 07:34 UTC on October 26, Bitquery had not observed outgoing transfers from that holding address to an exchange, bridge or mixer. It reported approximately 9,408.21 SOL consolidated there, although its separate public-node balance readings were taken earlier in the morning. This is a dated research snapshot. An independently verified current balance or post-cutoff movement history was not available for this article; the money should not be described as still stationary on October 27 without a fresh chain check.
Public visibility of the address creates investigative opportunities, but it does not mean the SOL has been frozen, seized or returned to victims. Native SOL has no centralized issuer that can simply blacklist a particular balance. Effective recovery would normally depend on control of the funds, cooperation from a receiving service or legally authorized intervention. DaveFinances’ analysis of stolen-crypto tracing versus actual recovery explains why locating a wallet and returning the assets are separate outcomes.
Bloom said it would reimburse the nine affected traders, directing compensation to new, secure wallets chosen by their owners, and said it was investigating possible involvement of a third-party provider. It also paused some services as a precaution. These are company commitments, not confirmation that repayments were made or that the cause has been determined. No independently verified completion schedule or final reimbursement record was available during this review.
An allegation that Bloom deliberately drained users would require evidence beyond the shared use of its service. Bitquery observed no flow between the attacker addresses and Bloom’s identified fee-collection wallet, and the victims represented only a small fraction of recent fee-paying addresses. Neither observation rules out every possible scenario, but neither supports asserting that Bloom itself orchestrated the theft.
What Controls Could Limit the Next Trading Bot Key Compromise?
Fast trading tools make an explicit trade-off: users can execute quickly without approving every transaction through a separate wallet prompt, but that speed often requires a service or signing infrastructure to exercise substantial authority over funds. For a trader maintaining multiple bot wallets, the loss exposure is the total balance reachable by the same key-management system, not merely the value of the next planned trade.
A practical containment model separates small trading balances from long-term holdings in wallets whose private keys have never been imported into a bot. This does not prevent all phishing or device compromises, but it limits what a compromise of a particular automation service can immediately reach. Abandoning an old bot account without replacing an exposed key does not achieve that isolation.
The concern extends to platforms responsible for keys or wallet infrastructure. DaveFinances previously reported CoinDCX’s admission that transfers continued through previously compromised deposit infrastructure. That was a different incident involving different assets and operational failures, but it illustrates why a wallet labelled inactive or retired must not automatically be considered safe.
For Bloom, the most useful follow-up would identify the key-generation and storage arrangements, whether private keys or signing requests were accessible to any vendor, whether the nine traders shared a technical dependency, and how dormant wallet credentials remained exposed. Independent incident review, concrete reimbursement receipts and an explanation of how resumed service avoids the same risk would carry more weight than an unsupported assertion that all other accounts are secure.
Until those questions are answered, the facts support a precise conclusion: 48 Bloom-linked wallets belonging to nine traders lost about $953,000 in SOL in a highly automated, key-authorized drain. Bloom has promised repayment; the attacker-controlled address was traced to a dated October 26 snapshot; and neither the blockchain signatures nor the current public record identifies the original source of the key exposure.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574