Forty-eight wallets linked to Bloom, an automated Solana trading service, lost a combined 9,408 SOL in a rapid series of transfers on Oct. 26, according to blockchain analytics cited by CryptoSlate. Bloom later said all nine affected users had been fully reimbursed, but the incident left unresolved how the transactions gained authority to move funds.
What happened to the wallets
Bitquery’s reconstruction identified 48 Bloom-associated wallets that transferred out 9,408 SOL. The transactions took place between 01:03:07 and 01:04:41 UTC on Oct. 26, making the incident a concentrated sweep rather than a series of isolated withdrawals over an extended period.
The wallets were linked to Bloom through previous fee payments and were grouped into nine traders. Bitquery said 24 of the 48 wallets had not paid Bloom trading fees during the previous month. Five had last paid a fee between January and May 2025, indicating that some affected wallets had been inactive through the service for a considerable period.
Bitquery described each transaction as a plain SOL transfer authorised by the affected wallet’s own key. Its analysis found no second signer and no token approval involved in the movements. That distinction matters because it points to control of the wallet’s signing authority, rather than simply an unauthorised change to a withdrawal setting inside Bloom.
Bloom said in an Oct. 26 update that its private keys had not been accessed or compromised. The company attributed the incident to a remote-code-execution vulnerability in a third-party module and said wallets that were not affected remained safe. Later the same day, Bloom announced that it had refunded all nine affected users, reporting the total as 9,408 SOL and linking nine repayment transactions.
The reimbursement addresses the financial loss reported by the affected users. It does not, by itself, establish how the attacker was able to produce valid wallet-authorising signatures.
Why Bloom’s withdrawal lock may not have stopped the transfers
Bloom’s documented withdrawal safeguard concerns the destination used by its withdrawal process. Users can set, lock or unlock that address through the service’s Withdraw menu. While locked, the destination cannot be changed; unlocking begins a 24-hour cooldown before a replacement address can be introduced.
That mechanism can make it harder for someone who has taken over a Bloom account to redirect funds through the normal withdrawal interface. It does not necessarily prevent a transfer created directly with the private key controlling a wallet.
Bloom’s homepage says its Extension, Manager and Telegram products share an execution engine. A wallet key used through another interface retains authority over the same assets. In general, a transaction on Solana includes instructions, signatures from accounts authorising the changes and a recent blockhash. Every required signer must provide a valid signature for the transaction to be accepted.
For a wallet controlled by one private key, anyone who obtains that key can create a new transfer to another destination without changing the withdrawal address saved inside a trading service. A valid owner-key signature can therefore be consistent with copied key material, or with misuse of a system capable of signing on the wallet’s behalf. The available analysis does not determine which of those routes was used in the Bloom incident.
That is why a locked withdrawal address and a compromised signing path represent different security questions. The lock may protect one service workflow, while a stolen or misused signing authority could operate outside that workflow.
The wider lesson about dormant bot wallets
The affected wallets’ trading history adds another dimension to the event. A wallet does not lose signing exposure merely because its owner stops using an automated trading service. If a controlling key has been copied and SOL remains at the address, the key may still be used to authorise a later transfer.
Bitquery also discussed a separate TradeWiz drain, while not establishing a common cause with the Bloom incident. It dated that sweep to Sept. 30 and counted 20,793 wallets drained of SOL. According to the analysis, fee-paying bot trades stopped 41 minutes into the main sweep, but the bot subsequently took 73% of the SOL involved. Two drained addresses later received fresh deposits and were emptied again within four seconds.
The examples illustrate the difference between changing access to a service and changing control over assets. Moving funds to a new interface does not remove the exposure if the same private key remains in use. Nor does importing that key into another application eliminate the risk. Assets moved back to the old address remain subject to the old key’s authority.
A genuinely new wallet controlled by an uncompromised key changes who can authorise future transfers, provided that key is not placed in a signing environment that remains exposed. Bloom said its refunds would be sent to secure wallets selected by the affected users, and its subsequent announcement said repayment had been completed.
Current Solana market picture
Moneyiar market data recorded SOL at $101.5978856709 as of Oct. 25, 2026, at 22:39 +03:30. The token was up 0.03% over 24 hours and down 1.52% over seven days.
The data also showed Compound at $21.1287447338, down 10.42% over 24 hours and up 0.3% over seven days; Nexus at $0.0000006151, up 1.61% over 24 hours and down 13.97% over seven days; and Rain at $0.0084289407, up 2.54% over 24 hours and down 8.14% over seven days. These figures are Moneyiar data at the stated times and are separate from the wallet-drain investigation.
