Bloom: one trading system across extension, web, and Telegram

The short answer

Bloom is a trading system with Telegram bots, a browser extension, web management, spot swaps, limit orders, sniping, copy trading, social-feed automation, multi-wallet execution, and an in-product bridge. Its public docs describe support for Solana, Ethereum, BSC, and Base; a separate FAQ also names Monad. Treat live chain support as a setting to verify, not a permanent list.

The interfaces are different control planes for the same account

Bloom's extension overlays supported trading terminals while reusing Bloom wallets, presets, and strategies. Orders created in the extension can appear in Telegram, and the extension can place Bloom-powered trades without requiring a separate wallet confirmation for every click. The host terminal, Bloom overlay, Telegram chat, and backend execution path are therefore layers of one workflow.

Bloom says the extension itself does not request private keys, wallet access, or transaction signatures. That is a useful claim about the extension surface. It does not mean the full Bloom account has no signing authority: Bloom wallets can be generated or imported elsewhere in the product and then used by the overlay.

A shared bot wallet is still a remotely operated hot wallet

Bloom documents generating wallets, receiving a private key, and importing an existing wallet by pasting its private key. It also recommends saving generated recovery material because the key message later becomes unavailable. The public guides reviewed for this article do not fully explain the backend encryption, storage, or signing architecture behind shared execution.

Do not import a primary wallet. Create a dedicated Bloom wallet, export and test its recovery path, fund it only with strategy inventory, and sweep excess assets to a wallet outside Bloom. A withdrawal-address lock with a 24-hour unlock delay can slow one form of theft; it cannot stop unauthorized swaps, malicious automation, or key use through an already authorized surface. Use the broader compartment model in wallet compartmentalization.

A trigger is not a fill, and a protection toggle is not a guarantee

Bloom supports copy presets, limit orders, launch snipers, AFK rules, social tasks, developer-sell actions, and automatic orders attached after buys. The docs say copy trading can use exact, percentage, or fixed amounts and optionally follow sells. Each mode can diverge through latency, partial fills, balance differences, filters, and the source wallet's transfers or hidden positions.

Limit or developer-sell detection only starts execution after Bloom observes the condition. Liquidity can disappear before the transaction lands. Buy/Sell Protection and anti-MEV routes can reduce specific exposure without validating the token, preserving the trigger price, or guaranteeing inclusion. Check the actual signature, route, output, and wallet delta.

Multi-wallet amount semantics can multiply the order

Bloom's extension can interpret an amount as a total split among selected wallets or as a full amount sent from every wallet. A 1 SOL action across five wallets can therefore mean 1 SOL total or 5 SOL total. The same ambiguity affects tips, fees, positions, and later exit rules.

Name wallets by strategy, keep the active set small, and confirm whether every amount is per-wallet or aggregate before submission. Multiple addresses under one controller are still one economic position; consolidate their exposure and P&L in the journal.

The platform fee is only the first cost layer

Bloom publishes a 1% fee on buys and sells, reduced to 0.9% for referred users. Add network fees, priority costs and tips, venue or launchpad fees, token taxes or extensions, price impact, slippage, and the cost of any Pro Account creation. Each automated leg can repeat those costs.

Bloom's bridge uses Houdini Swap and offers modes labeled public and private. That introduces a separate provider, quote, route, fee, destination-chain gas need, and failure model. “Private” is a provider feature label, not proof of anonymity. Verify both chain transactions and the destination balance.

A safer evaluation workflow

1. Enter through Bloom's official site. Verify the extension listing, bot username, Manager URL, and support channel independently.
2. Create a dedicated wallet. Back up the key offline, test recovery and withdrawal, set an address lock, and keep the balance minimal.
3. Map every surface. List the extension, Telegram bots, open host terminals, presets, active wallets, and linked tasks.
4. Run one confirmed micro-trade. Match the mint, pool, wallet, per-wallet amount, slippage, tips, signature, and settled delta.
5. Test automations one at a time. Measure trigger source, detection time, fill, cancellation, repeated orders, and behavior after a manual exit.
6. End the session deliberately. Cancel tasks, remove unused extension permissions, sweep excess funds, and verify that no instruction remains active.

What belongs in the journal

Record the Bloom surface, host platform, wallet set, chain, mint and pool, trigger source, per-wallet and total amount, slippage, protection mode, priority and tip, platform and venue fees, active follow-up orders, bridge provider and route, signatures, final deltas, and timestamp.

Primary sources