Bloom Crypto Bot Wallet Drains: What Happened and What Users Should Check

Bloom crypto bot users have reported unauthorized wallet transfers, while Bloom has publicly committed to reimbursing affected users and investigating the cause. Onchain Lens reported approximately 9,408 Solana (SOL), valued at about $954,000, associated with 49 suspected victims. Separately, Bloom’s publicly indexed response identified nine affected users. These figures describe different reporting scopes; they should not be treated as a reconciled incident total.

Our view is that the immediate priority is protecting remaining assets and documenting losses—not accepting an early explanation as the final cause. A reimbursement commitment matters, but it is different from completed compensation. Likewise, disconnecting a trading bot is not a complete remedy if someone else can still authorize transactions from the wallet.

This review reflects information available on October 26, 2026. The investigation remains developing, and the technical cause and complete reimbursement outcome were not independently established during this review.

What Is Bloom Crypto, and Which Product Is Involved?

In this incident, “Bloom crypto” refers to the BloomTrading trading-bot ecosystem, not simply any cryptocurrency or wallet carrying the Bloom name.

Bloom’s website presents three connected products: a browser extension, the web-based Bloom Manager, and Telegram trading tools. Its documentation describes automated trading functions and wallet management across multiple supported networks. (The most advanced cross-chain trading automation)

That product structure matters when investigating exposure. Someone who interacted with an extension may have a different history from someone who created a wallet through a bot or imported an existing wallet.

The relevant questions are therefore specific: Which product did you use? Which wallet was involved? What information or authority did you provide? What transactions actually occurred?

A shared name is not enough to establish that two products are connected. Readers should also avoid confusing BloomTrading with the separately named “Ill Bloom” wallet-generation vulnerability. A similar name does not demonstrate a common cause, operator, or affected-wallet population.

What Do We Know About the Bloom Wallet Drains?

The available evidence comes from different sources serving different purposes. User complaints describe individual experiences, monitoring accounts identify transaction patterns, and the platform describes its own response.

Those categories can overlap without being interchangeable.

The monitoring figures should remain attributed to Onchain Lens. This article has not independently reconstructed every transaction or established ownership of every address in the reported cluster.

The distinction is practical. A transaction can demonstrate that assets moved between addresses. Additional evidence is needed to establish whether a transfer was unauthorized, who controlled the addresses, and which product or credential enabled it.

Similarly, a platform’s statement can establish what it has promised. It cannot, by itself, demonstrate that the promise has been fulfilled.

Why Do Reports Mention Nine Users and 49 Wallets?

Users, wallets, and addresses are different units of measurement.

Bloom’s indexed statement refers to nine affected users. External monitoring refers to a broader suspected population. It would be premature to present these as two directly comparable customer counts.

One person can control several wallets. A monitoring dataset can also contain addresses whose relationship to a platform has not yet been confirmed.

Consider an illustrative example: one trader might maintain a main wallet, two trading wallets, and a separate wallet for automated strategies. Four affected addresses would not necessarily represent four affected people.

The reverse problem also matters. A platform’s initial confirmed-user count might cover only reports it has reviewed. That does not establish that every address in an external investigation belongs to an additional customer.

A properly reconciled incident report would explain its definitions and methodology. It would distinguish unique addresses, customer accounts, confirmed reports, and unresolved cases.

Until then, dividing one count by another to estimate “the percentage of victims being refunded” would produce a misleading result. The numerator and denominator have not been shown to describe the same population.

Has the Cause of the Bloom Incident Been Confirmed?

A final technical cause was not verified in this review.

Bloom’s public response describes an ongoing investigation. Reporting has discussed possible third-party involvement, but a possible explanation should not be presented as an established attack mechanism. (x.com)

Several questions remain separate.

Was an unauthorized transaction signed using an exposed private key? Was an application or service compromised? Did a user approve a harmful transaction? Were different users affected through the same mechanism?

Evidence supporting one possibility does not automatically eliminate the others. A suspicious transfer is the starting point for investigating authorization, not the complete explanation.

What Does HashDit’s BloomEVM Research Add?

A security analysis published by HashDit describes testing BloomEVM wallet flows. HashDit reported that wallet-generation and import interactions involved private-key information passing through backend infrastructure. Those are the researcher’s findings, not tests independently reproduced for this article.

This material adds a useful question about the meaning of wallet control: Can a service or its infrastructure access the information needed to authorize transactions?

However, its scope must remain clear. Research concerning a particular EVM product flow does not establish how the currently reported Solana transfers occurred. It also does not prove that every deployed version or every wallet followed an identical path.

Bloom’s own EVM documentation describes creating and importing wallets, including obtaining a private key and address. That confirms the relevance of examining wallet-management architecture, but documentation alone cannot resolve the incident.

The appropriate conclusion is that key handling deserves scrutiny. The unsupported conclusion would be that this research has already proved the current incident’s root cause.

Why Are Disconnecting, Revoking Permissions, and Replacing Keys Different?

These actions address different forms of access. Treating them as interchangeable can leave an important risk unresolved.

Disconnecting concerns an application’s connection to a wallet. Revoking permissions concerns authority previously granted to an application or other party. Replacing compromised keys means moving to a genuinely new wallet identity.

Phantom’s security guidance explicitly distinguishes disconnecting applications from revoking spending permissions. It also advises stopping use of a wallet when its recovery phrase, private key, or device may be compromised.

The simplest mental check is to ask: What could the other party still do without my next approval?

If the concern is an application connection, disconnecting addresses that connection. If continuing authorization exists, it needs separate review. If a private key has escaped the intended security boundary, changing interface settings does not remove the other party’s copy.

This is general wallet-security reasoning. It does not establish which scenario caused the Bloom reports.

What Should Bloom Users Check First?

Begin with your own exposure rather than assuming that every person who visited a website faces the same risk.

A user who only read a public page has a different exposure history from someone who imported a private key. An individual who signed a transaction needs to inspect what that transaction authorized.

The following sequence helps organize the investigation.

1. Establish Which Wallets Were Used

Record the public addresses you used with the product and the networks involved.

Distinguish a wallet created for automated trading from an existing wallet imported into the service. Also record whether you reused that wallet elsewhere.

Do not include recovery phrases, private keys, passwords, or authentication codes in a support ticket. Public addresses help identify transactions; secret credentials enable control.

2. Check Transaction History, Not Only the Displayed Balance

A changed balance can reflect transfers, trades, fees, or an application display issue. Inspect the relevant transaction records.

Record the transaction identifier, time, asset, amount, and destination. Preserve the original links alongside screenshots.

An explorer record does not necessarily identify the real-world controller of a destination. Keep “assets moved to this address” separate from “this person stole the assets.”

3. Review Connections and Continuing Permissions

Use your wallet provider’s official guidance to inspect connected applications and supported permissions.

Network-specific tools and authorization models differ. Do not assume an instruction for an EVM token approval describes every type of Solana account authority.

Phantom provides separate network-specific permission-review directions in its wallet-drain guidance. Access such tools through verified documentation rather than an unsolicited message.

4. Assess Whether a New Wallet Is Necessary

If signing credentials or the device itself may be compromised, a new wallet needs genuinely new keys.

Importing the old recovery phrase into another application does not create a new security identity. Phantom’s migration guidance explains that obtaining a fresh recovery phrase requires creating a new wallet and moving assets.

Before migration, account for staked assets and open positions as well as freely transferable balances. Some holdings require additional steps.

5. Avoid Repeatedly Funding a Wallet That Immediately Loses Deposits

If new deposits disappear almost immediately, stop making test deposits.

Phantom identifies this pattern as potentially consistent with a sweeper bot and warns against trying to outrun it with repeated transfers. This is a general warning, not a finding that a sweeper operated in every reported Bloom case.

What Does a Genuine Bloom Refund Require?

A reimbursement commitment should be evaluated through a payment process, not simply through the wording of an announcement.

Bloom has publicly committed to reimbursement. This review did not establish a complete record showing that every affected user had received compensation.

Readers assessing future updates should look for a clear progression:

The table is an editorial verification framework, not a claim that Bloom has published this exact process.

A replacement receiving address can make sense when the old wallet may be unsafe. However, the process used to register that address must also be authenticated.

A real support discussion should not require giving an agent the private key to the replacement wallet. Someone can send assets to a public receiving address without possessing its signing credentials.

Preserve the record of the address you submitted and how you submitted it. That helps distinguish a genuine payment error from impersonation or an altered destination.

How Should a Refund Amount Be Calculated?

A refund amount needs a defined unit of account.

The reported dollar value of stolen assets is a valuation at a particular time. It is not automatically the amount a platform has agreed to pay.

Consider this hypothetical example, unrelated to a verified Bloom claim:

A user loses 20 units of an asset valued at $100 each. The reported incident-time loss is $2,000.

If the asset later trades at $110, returning 20 units and returning $2,000 produce different outcomes. Neither method can be assumed without knowing the compensation terms.

A clear settlement should specify whether reimbursement is based on asset quantity, an agreed dollar valuation, or another method. It should also address any fees included in the claim.

This is why affected users should preserve both the quantity transferred and the timestamp. A screenshot of a rounded dollar balance may be insufficient for reconciling a payment later.

The same discipline prevents double counting. Several outgoing transfers may relate to one loss event, while a later transfer could be an attempted recovery or movement of remaining assets. Each record needs context.

Does “Self-Custody” Automatically Mean a Trading Bot Cannot Access Funds?

No. A custody label is less informative than the actual authorization arrangement.

A user needs to understand how a wallet is created, where signing occurs, whether credentials are imported, and what continuing authority the service receives.

An automation product must have some mechanism for executing the actions it promises. The important questions concern the scope, duration, and security of that mechanism.

For example, a system requiring approval for each transaction presents different controls from one that can execute a strategy while the user is offline. The difference does not automatically make either system fraudulent. It changes what users need to verify.

Useful documentation should explain what the operator can access, what it cannot access, and how that claim is supported. A reassuring phrase on a landing page is not a substitute for a clear technical explanation.

This is the broader lesson from examining the Bloom documentation alongside the security questions. Control should be evaluated through signing authority, not branding.

How Can Users Avoid Fake Refund and Recovery Messages?

A developing incident creates an audience that urgently wants assistance. That urgency can make impersonation harder to evaluate calmly.

Treat an unexpected message offering guaranteed recovery as a separate security decision. Do not assume that knowledge of your public wallet address proves the sender is legitimate.

Phantom’s support guidance states that its support team will not request recovery phrases or private keys. Its security material also identifies fake support chats and fraudulent verification requests as methods used to obtain wallet access.

For communications claiming to come from WEEX, use the WEEX Contact Verifier. It supports checks of websites, email addresses, phone numbers, Telegram IDs, and social accounts. It verifies WEEX-related channels; it is not a validator for Bloom’s refund process. (Check Contacts & Avoid Scams)

The WEEX Trust Center provides a broader starting point for reviewing WEEX security information and verification resources.

Neither resource reverses an external wallet transaction or establishes eligibility for compensation from another service.

What Would Show That the Bloom Incident Is Being Resolved?

A restored interface or resumed trading is not sufficient evidence of resolution.

A meaningful update should connect three outcomes: the affected population has been identified, the relevant security failure has been addressed, and accepted losses have been reconciled with actual compensation.

A technical explanation should describe the affected products or versions and the conditions under which exposure occurred. It should distinguish confirmed findings from remaining hypotheses.

A reimbursement update should explain what has been paid and what remains under review. Where public transaction records are appropriate, they should be understandable without exposing unnecessary personal information.

Finally, users need to know what changed. A service being available again answers an operational question. A documented change to the vulnerable process answers a security question.

For readers following the story, those are more useful milestones than a succession of increasingly confident statements.

WEEX‘s Editorial View

The most important issue in the Bloom crypto bot reports is the relationship between convenience and signing authority.

An automated interface can simplify trading while making the underlying access arrangement harder to see. Users need an accurate account of that arrangement before they can assess the risk.

Bloom’s reimbursement commitment should be judged by documented execution. The technical investigation should be judged by a clear account of scope, cause, and remediation. External wallet counts should remain attributed and carefully defined.

Until those pieces are reconciled, the responsible approach is to protect remaining assets, retain transaction evidence, and avoid treating either an early accusation or an early reassurance as the final answer.

FAQ

1. What Happened to the Bloom Crypto Bot?

Users reported unauthorized wallet transfers associated with BloomTrading. Blockchain monitoring described suspicious outflows, while Bloom’s indexed response acknowledged affected users and committed to reimbursement during an investigation. The complete technical cause was not verified in this review. (x.com)

2. Are Nine Users and 49 Wallets Contradictory Figures?

Not necessarily. A person can control several wallets, and different reports can use different confirmation standards. The figures require a reconciled methodology before they can be compared directly.

3. Has Bloom Completed All Refunds?

A complete reimbursement outcome was not independently established in this review. A commitment to pay should be distinguished from accepted claims, payment records, and final reconciliation.

4. Is Disconnecting Bloom Enough to Protect a Wallet?

Not if signing credentials have been compromised. Disconnecting an app, removing continuing permissions, and moving assets to newly generated keys address different risks. Follow the wallet provider’s verified guidance for the relevant exposure.

5. Does This Incident Prove the Solana Network Was Hacked?

No. Reports of unauthorized transfers involving a trading tool do not, by themselves, establish a failure of the underlying blockchain. Determining the cause requires evidence about how the transactions were authorized.

Sources