// BLOOM · PRIVACY CENTER · v2024.1
PRIVACY & DATA
Bloom is non-custodial and runs primarily in your browser. We use no third-party advertising or analytics trackers, set no marketing cookies, and store nothing about you on our servers. The notes below explain exactly what data leaves your device — and which features are live on-chain versus visual previews.
PRIVACY DASHBOARD35/100
Protected metadata5/25
Private Mode off — metadata visible in the UI (still encrypted at rest).
Protected routing0/25
Normal submission (public mempool).
Protected execution25/25
User approval + wallet signature required. No auto-execution, no hidden signing.
Protected storage5/25
Encryption unavailable in this environment.
Protected
✓ Copilot memory (encrypted at rest)
✓ Simulations (encrypted at rest)
✓ Strategy metadata (masked in Private Mode)
Not protected
✗ Public settlement (on-chain inclusion)
✗ Public blockchain visibility (amounts, addresses, transfers)
✗ Submission routing (currently normal / public mempool)
Bloom protects metadata, local data, and (opt-in) submission routing. It does not make on-chain transactions private — settlement is always public on Base. Full on-chain privacy is not claimed.
PRIVATE MODEOFF
Bloom protects strategy metadata. On-chain transactions may still be publicly visible. When on, Bloom masks strategy metadata across the interface (Copilot, simulations, portfolio, balances, briefing). Your local Copilot memory and simulation history are encrypted at rest regardless of this toggle.
SUBMISSION ROUTING
Choose how transactions are submitted. Protected Submission forwards your signed tx to a private RPC (out of the public mempool) instead of broadcasting normally. You still approve + sign every transaction — this never changes signing.
PUBLICVisible interface data.
PRIVATEHidden from casual view when Private Mode is on.
ENCRYPTEDEncrypted before local storage.
QUANTUM-READY SECURITY LAYERCHECKING…
Quantum-ready protection for agent memory, strategy data, and execution logs.
Bloom wraps sensitive off-chain data in a hybrid-encryption envelope built for post-quantum cryptography. Symmetric primitives (AES-256-GCM, HMAC-SHA-256) provide long-term data protection today, and a pluggable provider lets Bloom layer in post-quantum KEMs and signatures (ML-KEM / Kyber, ML-DSA / Dilithium) via Open Quantum Safe (liboqs) or Cloudflare CIRCL without changing call sites.
Hybrid encryptionAES-256-GCMAudit signingHMAC-SHA-256Post-quantum cryptographyReady (pluggable provider)ProviderBloom Hybrid Baseline · AES-256-GCM + HMAC-SHA-256 (post-quantum ready)
PROTECTED OFF-CHAIN DATA
■ Agent MemoryAutonomous agent reasoning, journal, and learned state.
■ Strategy ConfigsRisk limits, profiles, and strategy parameters.
■ Oracle ReportsForecasts, consensus, and intelligence outputs.
■ Execution LogsTrade history, quotes, and execution outcomes.
■ Risk ReportsToken risk assessments and security findings.
■ User PreferencesLocal settings and personalization.
Scope: this protects off-chain Bloom data at rest. On-chain transactions are still signed by your wallet with its existing cryptography — quantum-readiness here is about long-term protection of stored data, not wallet signatures.
PRINCIPLES
■ NON-CUSTODIALBloom never holds your keys or funds. Transactions are signed by your wallet.
■ NO TRACKERSNo ad networks, no analytics SDKs, no fingerprinting. Topics API / FLoC are disabled via Permissions-Policy.
■ LOCAL-FIRST STATETheme and this privacy acknowledgement live only in your browser's localStorage.
■ MINIMAL DISCLOSUREOnly your public wallet address is shared with the RPC/Privy to read balances and connect.
WHAT LEAVES YOUR BROWSER
Morpho Blue API
blue-api.morpho.org
Read live vault data (APY, TVL) on Base. Public, read-only.
RPC provider
NEXT_PUBLIC_RPC_URL
On-chain reads/writes via viem/wagmi (balances, deposits, withdrawals).
Privy
*.privy.io
Wallet connection & authentication. Only used once you connect.
MoonPay (via Privy)
*.moonpay.com
Optional fiat on-ramp. Only contacted if you choose to fund.
Tip: set a private NEXT_PUBLIC_RPC_URL (your own Alchemy/Infura key) to reduce third-party correlation of your address with your IP.
FEATURE TRANSPARENCY · LIVE vs PREVIEW
Morpho Vaults (deposit / withdraw)
Real ERC-4626 transactions on Base via your connected wallet.
Wallet connection
Real wallet auth via Privy. Only your address is read.
Agent Wallet (create / fund)
UI preview of a future ERC-4337 smart account. No funds move yet.
Strategy deployment (loop / leverage)
Catalog & configuration UI. Execution is gated and not yet live.
Agentic trading terminal
Charts, signals and PnL are generated locally in your browser for demonstration.
YOUR CONTROLS
Privacy acknowledgement: not acknowledged
▸ PRIVACY ROADMAP · INTERNAL / RESEARCH
Current: v0.1 protects strategy METADATA and LOCAL strategy data (UI masking + at-rest encryption).
Next: Future versions may protect routing and execution metadata (research above).
Full on-chain privacy is NOT claimed.
Private routingresearch
Route strategy submission so the link between user wallet and target vault is not trivially observable.
• Submit intents to an off-chain router that batches/abstracts the originator.
• Decouple 'who asked' from 'what executed' at the routing layer.
⚠ Router becomes a trust/centralization point.
⚠ On-chain settlement is still public.
Shielded executionresearch
Execute deposits/withdrawals through a shielded pool / commitment scheme so amounts and counterparties are obscured.
• Commitment + nullifier model (Tornado-style) for vault flows.
• Requires audited circuits and careful UX for proofs.
⚠ Regulatory/compliance considerations.
⚠ Liquidity fragmentation; complex withdrawal UX.
Encrypted strategy submissionplanned
Encrypt the user's strategy/intent end-to-end so only the executor can decrypt at execution time.
• Builds on v0.1 local encryption.
• Pair with relayer or TEE for decrypt-at-execution.
⚠ Key management; executor still learns the intent at execution.
Stealth agent walletsresearch
Per-action stealth addresses for agent wallets so activity is not linkable to one persistent agent address.
• Stealth address (ERC-5564-style) derivation for agent actions.
• Improves unlinkability of position history.
⚠ Gas/UX overhead.
⚠ Recovery + bookkeeping complexity.
Relayer-based executionresearch
Submit signed intents via a relayer so the funding wallet does not directly originate the on-chain tx.
• Meta-transactions / account abstraction (ERC-4337) paymasters.
• Breaks the naive sender↔strategy link.
⚠ Relayer trust + censorship.
⚠ Still public settlement.
Intent-based routingresearch
Express goals as intents resolved by solvers, hiding the exact path/strategy from casual observation.
• Solver competition can obscure the chosen route.
• Aligns with the existing Copilot intent model.
⚠ Solver trust; MEV.
⚠ Intent leakage to solvers.
FHE / TEE / zk privacyresearch
Cryptographic execution privacy: FHE for compute-on-ciphertext, TEEs for shielded execution, zk for verifiable private state.
• zk for private balances/proofs.
• TEE for confidential strategy execution.
• FHE is early but promising for private compute.
⚠ FHE performance immature.
⚠ TEE side-channel/trust assumptions.
⚠ zk circuit + audit cost.
Veilnet-style privacy integrationresearch
Integrate a dedicated privacy network/layer for shielded routing + execution metadata protection.
• Evaluate third-party privacy networks for routing/execution.
• Pluggable behind the existing execution engine.
⚠ External dependency + trust.
⚠ Integration + audit surface.
Public blockchain limitations
• Confirmed transactions (sender, recipient, amount, contract) are public on Base.
• Vault deposits/withdrawals are visible on-chain and via explorers/indexers.
• Wallet balances and token transfers are publicly queryable.
• v0.1 does NOT hide any of the above — it protects local strategy metadata only.
▸ BLOOM PRIVACY ROADMAP v2 · PRIVATE ROUTING · INTERNAL / RESEARCH
Protect execution INTENT (pre-mempool) in addition to v0.1's metadata + local-data privacy, via a pluggable private-routing layer behind the existing execution engine.
Research + prototype scaffolding only. No signing, relaying, broadcasting, or execution is implemented.
Final on-chain settlement stays publicly visible on Base. Full on-chain privacy is NOT claimed.
Architecture (pluggable, behind the execution engine)
1. Copilot Intent — User expresses a goal (deposit/withdraw/swap). Already exists.
Sanitize into an abstract RouteIntent (size buckets, opaque target refs) — no raw secrets.
2. Privacy Router (abstraction) — Select a routing strategy + build a read-only plan; single seam the rest of the app calls.
Provider interface has NO execute() — execution stays in the audited execution engine, gated by flags.
3. Provider Adapters — private-rpc / mev-protected / intent-based / relayer / stealth-wallet / encrypted-orderflow / privacy-network.
Each adapter is independently audited + feature-flagged; default OFF.
4. Existing Execution Engine — User confirmation + wallet signature (unchanged). Only the SUBMISSION transport changes per provider.
No new signer logic; consent + signing remain exactly as today.
5. Settlement (Base) — On-chain inclusion + settlement.
Public regardless of routing — this is the honesty boundary.
Approaches ranked by research privacy score (read-only preview)
encrypted-orderflowprivacy 88/100 · mempool strong · MEV strong
Cost +$0.1–1 · sender-unlinkability partial · amount strong
intent-basedprivacy 75/100 · mempool strong · MEV strong
Cost +$0–0.2 · sender-unlinkability partial · amount partial
privacy-networkprivacy 75/100 · mempool strong · MEV partial
Cost +$0.1–1.5 · sender-unlinkability strong · amount partial
private-rpcprivacy 50/100 · mempool strong · MEV strong
Cost +$0–0.05 · sender-unlinkability none · amount none
mev-protectedprivacy 50/100 · mempool strong · MEV strong
Cost +$0–0.1 · sender-unlinkability none · amount none
relayerprivacy 38/100 · mempool partial · MEV partial
Cost +$0.02–0.3 · sender-unlinkability partial · amount none
stealth-walletprivacy 25/100 · mempool none · MEV none
Cost +$0.05–0.5 · sender-unlinkability strong · amount none
Phased rollout
Phase 1: Private RPC + MEV protection low effort
Keep txs out of the public mempool and stop front-running — near-zero cost, no UX change.
UX: Optional 'Protected submission' toggle; otherwise invisible.
Phase 2: Intent-based execution medium effort
Route swaps via solver/auction networks to obscure path + protect against MEV.
UX: Swaps may settle via batch auction; better price + privacy.
Phase 3: Relayer + stealth agent wallets high effort
Decorrelate the funding wallet from on-chain actions and unlink agent history.
UX: Agent wallet becomes a smart account; per-action stealth addresses (opt-in).
Phase 4: Encrypted order flow + privacy network high effort
Hide intent AND amount pre-execution via threshold/TEE encryption or a dedicated privacy network.
UX: Strongest pre-execution privacy where infrastructure exists on Base.
Tradeoffs
• Privacy vs latency: Encrypted/threshold + auctions add inclusion latency vs a direct private RPC.
• Privacy vs cost: Stealth wallets + encrypted flow add gas/fees; private RPC is ~free.
• Privacy vs decentralization: Relayers/builders/solvers/committees introduce trust + censorship points.
• Privacy vs UX: Account migration, stealth bookkeeping, and recovery add user complexity.
• Pre-execution vs settlement: All approaches still settle publicly on Base — they hide intent, not the final record.
Cost (research estimates / action)
• Private RPC: ~$0 (sometimes rebates)
• MEV-protected: ~$0–0.10 (often net-positive)
• Intent-based: $0–0.20 (often offset by price improvement)
• Relayer (4337): $0.02–0.30 (bundler/paymaster premium)
• Stealth wallets: $0.05–0.50 (fund + sweep overhead)
• Encrypted order flow: $0.10–1.00 (early infra)
• Privacy network: $0.10–1.50 (provider-dependent)
Security
⚠ Every transport (RPC/relayer/builder/solver/committee) is a trust + liveness point — always provide a clearly-labeled fallback.
⚠ Never let any provider construct calldata or move funds without the user's explicit signature (consent stays in the execution engine).
⚠ Stealth + encrypted approaches add key-management risk — design recovery before enabling.
⚠ Audit each adapter independently; ship behind a default-OFF feature flag.
⚠ Be explicit in-UI that settlement is public; never imply full anonymity.
User flow — default vs private routing
Default:
1. User: 'Deposit 1,000 USDC into the best vault'
2. Copilot builds the action preview (as today).
3. User confirms → wallet signs → tx broadcasts via the normal RPC → public settlement.
Private routing (opt-in):
1. User enables 'Protected submission' (Private Mode → routing).
2. Copilot builds the SAME action preview + a read-only ROUTE PLAN (provider, privacy score, est. cost, trust notes).
3. User confirms → wallet signs the SAME tx/intent → submitted via the chosen private transport (e.g., private RPC) instead of the public mempool.
4. On transport failure, Bloom shows a privacy-downgrade notice before any public fallback.
5. Settlement is still public on Base — the UI says so plainly.
Recommendation
Phase 1 (Private RPC + MEV protection): highest privacy-per-effort, ~free, no consent/signing changes, easy fallback.
Phase 2 (intent-based) for swaps, then evaluate Phase 3/4 as Base infra matures.
Keep execution in the audited engine; private routing only changes the SUBMISSION transport, never the signing/consent model.
Research + prototype scaffolding only. No execution is implemented; the planner's execute path throws by design. On-chain settlement remains public on Base.