Bloom's Solana (SOL) Wallets Drained of 9,408 SOL in 94-Second Signing Breach

48 Wallets Drained in 94 Seconds

Something in the signing chain of Bloom, an automated trading service built on Solana (SOL), failed on Monday, and the exact mechanism behind it is still unconfirmed. Between 01:03 and 01:04 UTC on October 26, 48 wallets connected to the service sent a combined 9,408 SOL to an outside address, on-chain data shows. The entire outflow took roughly 94 seconds, first transfer to last. Every drained crypto wallet belonged to one of nine users of the service, and the wallets were identified as Bloom-linked through their fee-paying history with the platform.

The transactions themselves were unremarkable in form: ordinary SOL transfers on the Solana mainnet, signed with the wallets' own owner keys. There was no separate approval step to bypass and no extra signature to forge. Whoever produced those signatures could move funds as the legitimate owner, which put the question of access ahead of any question about the service's internal controls. Bloom does provide a lock on the withdrawal address, and even after a user unlocks it, a 24-hour wait applies before the address can be changed. Those safeguards count when the risk is a compromised service account or a hasty withdrawal. They count for little once a party outside the service can sign with the private keys directly. The Solana (SOL) network itself was not breached; the failure sat in one service's key management, not in the chain that processed the transfers.

The Solana (SOL) price is a side matter in this story; what moved was 9,408 SOL out of user balances rather than the market as a whole. The event has turned attention back to how automated trading bots hold authority over user funds, because a service that keeps standing signing rights over many wallets concentrates exactly the exposure that surfaced here.

24 of 48 Wallets Had Gone Quiet

What makes the incident broader than a single theft is how little some of the affected wallets were being used. On-chain analysis found that 24 of the 48 wallets had paid no Bloom trading fees in the month before the incident, and five of them had last paid fees between January and May of 2025. Users who had stepped away from the bot months ago still lost funds, because the wallets kept the signing arrangement the service had set up. Stopping use of an automated trading service does not by itself remove the exposure; the signing authority stays in place until the keys are changed.

Bloom's account of the cause differs from a straightforward key leak. On October 26, the company denied that private keys had been copied and attributed the incident instead to a remote code execution vulnerability in an external module, a class of flaw that lets an attacker run code where the signing happens. Whether keys were actually duplicated, or a system holding signing power was abused, is not confirmed; the company's statement and the on-chain record do not settle it between them.

The financial side, at least, has been closed. Bloom reimbursed all nine affected users in full on the day of the incident, returning the entire 9,408 Solana (SOL) that left the wallets. That payment is a discretionary backstop from the operator, not a claim on DeFi insurance, and no rule obliges a future operator to repeat it. What stays open is the question underneath the reimbursement: the route by which the attacker obtained signing authority has not been established.

What the Post-Mortem Leaves Open

The reach of the same design is the part to weigh. Withdrawal locks and 24-hour delays are built to stop account-level mistakes and rushed changes; they do not constrain anyone who can already sign as the owner. The failure class therefore extends to any deployment that keeps persistent signing authority over user wallets, idle ones included, until keys are rotated. Bloom's module explanation is the team's own post-mortem rather than an independent finding, so the unconfirmed access route remains the fact to watch. If signing material did leak, balances would need to move to wallets managed under fresh keys to prevent repeat theft; self-custody hardware such as the Tangem Mobile Wallet is one such path, and idle service-linked balances carry standing risk until that move happens.