Bloom Trading theft reports total 9,408 SOL; team pledges compensation for 9 wallets

What the reported loss figures cover

Odaily published its report at 12:26 SGT on October 26. It says users reported stolen wallet assets and that about $954,000 had moved to a suspected theft address. The report attributes the observation to Onchain Lens, which identified 9,408 SOL taken from 49 victims through one theft wallet. It also says the final total could be higher. That leaves the reported amount as a monitoring snapshot rather than a completed incident accounting. Odaily

PANews carries the same total, victim count and largest individual loss. Both outlets attribute these figures to Onchain Lens. Reading two publications therefore gives readers two accessible accounts of the observation, but the shared attribution does not supply a second on-chain investigation. We have retained that attribution rather than presenting the loss figure as an independently reproduced calculation. PANews

The dollar amounts are the reports' approximate conversions. They are not a live SOL quotation. A user comparing their own loss with the headline should start with the quantity of SOL and the corresponding transaction, then record any valuation method used in a claim. Applying a later token price would answer a different question from the one the original report addressed.

The largest reported theft also needs its own scope. The 1,636 SOL figure describes an individual loss in the monitoring account. Neither article says it represents the largest Bloom compensation claim. Carrying it into a compensation calculation without a matching wallet would join two pieces of information that the sources have not connected.

The compensation commitment has a narrower stated count

PANews describes Bloom Trading as a cross-chain trading automation platform. Its report says Bloom will fully compensate losses suffered by nine affected wallets, with funds sent directly to new, secure addresses designated by each wallet owner. The same report says the team is investigating the root cause, including whether a third-party service provider was compromised.

This is a reported commitment. The opened article does not include a completed payout ledger, transaction signatures for reimbursements, a payment deadline or a detailed eligibility process. A reader can therefore describe the pledge and its stated delivery method. A claim that victims have been reimbursed would require evidence of payment beyond the statement reported here.

The nine-wallet count should remain attached to the team's response. The 49-victim count belongs to the monitoring report. One may eventually prove to be a subset of the other, but the opened material does not establish that relationship. Subtracting nine from 49 would not produce a verified count of excluded users. Dividing the reported loss by nine would not produce a verified average compensation amount either.

For an affected user, the useful next question is specific: does the team recognize the address that lost the assets, and what loss amount has it assigned to that address? A reply confirming a general commitment is less useful than a record linking a particular wallet to a particular claim. Keep that correspondence with the transaction evidence so that later changes in the incident totals do not erase the original claim details.

Check transactions before treating a balance change as a confirmed loss

Solana's transaction documentation says a transaction includes instructions, signatures authorizing the changes and a recent blockhash. It also explains that instructions execute together: if an instruction fails, the transaction fails and the state changes revert, although fees are still charged. This is relevant when reviewing a suspicious wallet history because a failed transaction and a completed transfer are different records. Solana transaction documentation

Start a record for each transaction you believe moved assets without authorization. Save its signature, the originating wallet, the destination displayed in the transaction record, the asset quantity and the observed status. If a wallet interface lists several actions under one transaction, preserve the full transaction view instead of copying only the first line. The official documentation establishes that one transaction can contain more than one instruction; a single visible label need not describe every instruction.

Compare those records with the wallet history you already recognize. Mark which transfers you initiated and which you dispute. Keep a separate note of ordinary trading activity around the same time. This is a proposed way to organize a claim, not an assertion that every transfer beside the incident was malicious. It also avoids treating the entire wallet's turnover as a loss amount.

A screenshot can help preserve what an app displayed, but include the transaction signature in the written record. Solana identifies signatures as part of a transaction's structure. Recording that identifier gives the team a specific transaction to review, rather than asking it to infer a transfer from a cropped balance screen. The opened news reports do not supply a complete victim-address roster for readers to compare against their own accounts.

What affected users can do now

Odaily relays Onchain Lens's advice to disconnect the wallet and move remaining assets to a new wallet. That instruction is attributed to the monitor; the report does not establish the mechanism that enabled the theft. Follow the response to the incident without turning the advice into a diagnosis of a compromised key, a malicious approval or a breached service provider.

Before taking another trading action, review which wallet was connected to Bloom and which wallet still holds assets you intend to protect. Keep the affected address in your records even if you stop using it. PANews says the team's proposed compensation would go to new addresses specified by owners, so the old address and replacement address serve different purposes in that process. Record each clearly rather than overwriting one with the other.

If you are waiting for compensation, verify the communication channel and the exact receiving address before accepting a proposed payment arrangement. Ask for the recognized loss amount and payment status in writing. The opened report describes direct transfers to replacement addresses; it does not describe an advance payment, a recovery deposit or a new trading requirement. Do not infer extra steps from unsolicited messages that merely repeat the headline.

Readers who use centralized exchanges alongside on-chain wallets should review their own transfer history rather than assuming the report concerns exchange balances. The sources report wallet theft connected with Bloom users. They do not identify a centralized exchange breach, suspend an exchange's SOL service or establish that any named venue's accounts were affected. Use the NexuAlpha exchanges directory to locate venue information, and check the actual account record for a transfer you need to reconcile.

What would establish recovery and explain the cause

The next useful incident update would connect the currently separate facts: the transactions included in the loss assessment, the wallets accepted for compensation and the transfers that settle those claims. A payment status attached to a wallet would answer a different question from a general statement that compensation is planned. A transaction record attached to a payment would give the recipient something concrete to match with their own history.

The cause remains under investigation in the response reported by PANews. Its reference to a third-party service provider is an investigative possibility, not a finding that such a provider was breached. The opened material does not identify a responsible vendor, name a vulnerable component or describe a completed fix. Those details should come from an incident report rather than from the fact that several wallets lost assets.

A reader deciding whether to use the automation service again can ask for the explanation of the affected access path and the changes made before resuming activity. A compensation promise answers the question of who plans to bear recognized losses. It does not, by itself, explain how transactions were authorized or which access needs replacing. The separate questions deserve separate answers from the team.

For now, keep the 9,408 SOL monitoring figure, the 49-victim observation and the nine-wallet compensation commitment in their stated scopes. Preserve your own transaction evidence and watch for a wallet-specific payment confirmation or a published explanation of the cause. Broader venue research can continue through the exchanges directory; the unresolved part of this event is the relationship between the reported losses, accepted claims and actual reimbursements.