Bitquery’s reconstruction reports that 48 wallets associated with Bloom, an automated trading service, lost 9,408 SOL through transfers signed by the wallets’ own keys.
Bloom documents a lock that prevents changes to a user’s withdrawal destination, yet a copied key can authorize transfers outside that service interface.
In an Oct. 26 update, Bloom denied that private keys had been accessed or compromised. The account attributed the incident to a remote-code-execution vulnerability in a third-party module and said unaffected wallets were safe.
Later on Oct. 26, Bloom announced that all nine affected users had been fully refunded, claiming a total of 9,408 SOL and linking nine transactions.
That leaves two separate issues for users: compensation for the loss and the authority that could move funds from a wallet.
What the withdrawal lock controls
Bloom’s FAQ tells users to keep their withdrawal address locked, saying that the address cannot be changed while locked and that unlocking starts a 24-hour cooldown before changes are allowed.
The withdrawal guide places Set Address, Lock Address, and Unlock Address in the Withdraw menu, accessible from the home screen or through the /withdraw command. The documented safeguard delays replacement of the destination used in that process.
The lock gives someone with a compromised service account a barrier against withdrawal redirection through that process.
Bloom’s product homepage describes the Extension, Manager, and Telegram products as sharing an execution engine. When the same wallet key is used through a different interface, it retains the same authority over the funds.
Bitquery reports that the full drains ran from 01:03:07 to 01:04:41 UTC on Oct. 26. It describes each as a plain SOL transfer signed only by the affected wallet’s key, with no second signer or token approval involved.
The Solana Foundation’s transaction documentation explains that a transaction carries instructions, signatures from the accounts authorizing the changes, and a recent blockhash. Its signing guide says every required signer must provide a valid signature.
For a wallet controlled by one private key, possession of that key gives control over its funds. An attacker who copied it could create a fresh transfer to a different destination without changing the withdrawal address saved inside a trading service.
Solana’s guide distinguishes holding a local key from requesting signatures through a key-management or managed-wallet backend. A valid owner-key signature can be consistent with copied key material or misuse of a signing path.
The owner-key signatures described by Bitquery sit alongside Bloom’s denial of private-key compromise. Determining which signing path was abused would determine whether the incident involved a copied secret or access to a system that could sign with it.
Where signing authority persists
The age of the affected wallets gives the incident a consequence beyond active bot users. Bitquery found that 24 of the 48 wallets had paid no Bloom trading fee in the preceding month, while five last paid one between January and May 2025.
Bitquery associated all 48 wallets with Bloom through earlier fee payments and grouped them into nine traders. It acknowledged that two of those groups rely mainly on the drain order.
If someone has copied its controlling key, a long pause in trading doesn’t prevent them from signing a new transfer when funds remain there.
The separate TradeWiz drain offers a dated example of persistent signing exposure, without establishing a shared cause with Bloom. Bitquery dates the main sweep to Sept. 30, and counts 20,793 wallets drained of SOL.
Fee-paying bot trades stopped 41 minutes into the sweep, but Bitquery reports that the bot took 73% of the main-sweep SOL afterward.
It also reports that two drained TradeWiz addresses received new deposits and were emptied again within four seconds. Depositing into an address after its controlling key has escaped can put the new funds under the same attacker’s authority.
If a sole controlling key has escaped, moving assets to a fresh wallet governed by an uncompromised key takes those assets outside the old key’s authority.
Keep the new key outside any signing environment the attacker can still use, since importing the same secret into another app preserves the same authority, so does returning funds to the old address.
Changing access to a service and changing control over assets have different effects. A destination lock can still protect the service’s withdrawal process, while a service-side repair may address a compromised signing path. Neither action can erase a copy of a private key already held elsewhere.
In its reimbursement promise, Bloom said funds would go to secure wallets designated by affected users, and its later announcement says it completed repayment.
For users assessing an old bot wallet, the key distinction is whether they changed where they log in or the authority governing the assets. When a key has been copied, a new interface leaves the old exposure in place. A fresh, uncompromised key changes who can authorize the next transfer.