BTC $77,410 
ETH $2,232 
MGLOEURO $111,813 
USDT $0.9991 
BNB $698.69 
XRP $1.25 
USDC $0.9997 
SOL $96.56 
TRX $0.3335 
FIGR_HELOC $1.03 Hacks & Security · Explained
Hackers drain 9,408 SOL from Bloom bot wallets as copied key is blamed
Bitquery traced the losses to 48 wallets whose own keys signed the transfers, while Bloom denied a private-key compromise and refunded nine users.
Key takeaways
- Owner-key signatures. Bitquery says every drain was a plain SOL transfer signed only by the affected wallet's key, with no second signer or token approval.
- Refunds completed. Bloom said all nine affected users were repaid in full, totaling 9,408 SOL across nine transactions.
- Lock limits. Bloom's withdrawal-address lock blocks redirection through its interface, but a copied key can authorize transfers outside it.
What happened
A reconstruction by blockchain data firm Bitquery has found that 48 wallets associated with Bloom, an automated trading service on Solana, lost 9,408 SOL through transfers authorized by the wallets' own keys. The drains ran from 01:03:07 to 01:04:41 UTC on Oct. 26, according to the analysis, which was reported by CryptoSlate and Blockonomi.
Bitquery described each movement as an ordinary SOL transfer carrying a signature from the affected wallet alone. No second signer and no token approval were involved, which places the incident in the category of key control rather than a contract exploit or an allowance granted to a malicious address.
Bloom pushed back on the framing of a key theft. In an Oct. 26 update, the service said no private keys had been accessed or compromised, attributed the incident to a remote-code-execution vulnerability in a third-party module, and stated that wallets outside the affected group remained safe. Later the same day, Bloom said all nine affected users had been reimbursed in full, putting the total at 9,408 SOL and linking nine transactions as evidence.
First $118.07Latest $96.79-18.0% over the period
Points are daily observations, not closing prices.
Why it matters
The episode leaves users with two separate questions: whether they are made whole, and who holds the authority to move assets out of a wallet. Bloom's documentation addresses only the second in part. Its FAQ urges users to keep their withdrawal address locked, noting that a locked address cannot be changed and that unlocking begins a 24-hour cooldown before any new destination can be set. The feature sits in the Withdraw menu, reachable from the home screen or through the /withdraw command.
That safeguard is designed to stop someone who has taken over a service account from redirecting payouts through Bloom's own withdrawal flow. A copied private key operates differently. Whoever holds it can sign a fresh transfer to a destination of their choosing without touching the address stored inside the trading service, so the cooldown never comes into play. Bloom's homepage says its Extension, Manager and Telegram products share a single execution engine, meaning the same wallet key carries the same authority whichever interface is used.
What the data shows
Bitquery tied all 48 wallets to Bloom through earlier fee payments and sorted them into nine traders, cautioning that two of those groups were identified mainly by the order in which the drains occurred. The inactivity is notable: 24 of the wallets had paid no Bloom trading fee in the month before the incident, and five had last paid one at some point between January and May 2025.
Solana Foundation documentation explains that a transaction carries instructions, signatures from the accounts authorizing the changes, and a recent blockhash, and that every required signer must supply a valid signature. For a wallet controlled by a single private key, possession of that key is enough to move the funds. The documentation also separates holding a key locally from requesting signatures through a key-management or managed-wallet backend. Blockonomi reported that SOL traded at $96.44 when it published its account, down 3.6% over 24 hours.
Background
A separate drain on the TradeWiz bot, documented by Bitquery, shows how long that kind of exposure can persist. The main sweep there is dated to Sept. 30 and counted 20,793 wallets stripped of SOL. Fee-paying bot trades stopped 41 minutes into the sweep, yet Bitquery reports the bot still captured 73% of the main-sweep SOL afterward. Two drained TradeWiz addresses later received new deposits and were emptied again within four seconds. No shared cause between the two incidents has been established.
What is still unclear
What remains unresolved is which signing path was abused. A valid owner-key signature is consistent both with copied key material and with misuse of a system that signs on a user's behalf, and the reports do not settle the question. It is also unknown whether the affected users had the withdrawal-address lock enabled when the transfers were made.
What to watch
For anyone reviewing an older bot wallet, the useful distinction is between changing where you log in and changing which key governs the assets. Moving funds to a fresh wallet controlled by an uncompromised key takes them outside the old key's reach, provided the new key is kept away from any signing environment an attacker can still access. Importing the same secret into another application, or sending funds back to the old address, preserves the original exposure regardless of how the service itself is patched.
Questions readers ask
Did Bloom lose private keys?
Bloom said private keys were not accessed or compromised and pointed to a remote-code-execution flaw in a third-party module. Bitquery's finding that transfers were signed by each wallet's own key does not by itself establish whether a key was copied or a signing system was misused.
Does locking a withdrawal address prevent this kind of drain?
No. The lock stops the saved withdrawal destination from being changed through Bloom's interface and imposes a 24-hour cooldown on unlocking, but a holder of the private key can sign a transfer to any address directly.
Were affected users repaid?
Yes. Bloom said all nine affected users received full reimbursement totaling 9,408 SOL and published links to nine transactions.
