Legal

Privacy Policy

Last updated: June 29, 2026

Summary

Sombra is a self-custody, post-quantum privacy wallet for Solana. We don’t collect personal data, and your private keys never leave your device. The Wallet does include optional, anonymous analytics and crash reporting that you can switch off at any time in Settings (see Section 5). Below is the full breakdown of what data exists, where it lives, and what crosses a network. One important exception in this build: if you use the default remote prover, the proving server operator can temporarily read your decrypted transaction inputs (amounts, token types, and destinations) while a proof is being generated. See Section 4 for detail, and switch to Local prover mode if you require zero trust.

1. Who we are

The Sombra wallet (the “Wallet”) is published by Bonsol Labs Inc. (“Bonsol”, “we”, “us”). This Privacy Policy covers the Sombra browser extension, the Sombra prover daemon, and the marketing site at sombra.tech.

2. Data we do not collect

  • No accounts, no sign-up, no email required to use the Wallet.
  • No personal data, account, or persistent user identifier — the optional analytics and crash reporting described in Section 5 are anonymous and assign no distinct ID to you.
  • No third-party advertising or marketing trackers inside the Wallet (no Google Analytics, Mixpanel, ad networks, or equivalents).
  • No tracking cookies inside the Wallet.
  • No clipboard scanning, no keystroke logging, no screen capture.
  • No sale of data. Ever. There is no data to sell.

3. Data stored locally on your device

The Wallet uses your browser’s local extension storage (chrome.storage.local). Nothing in this list is transmitted to Bonsol.

  • Encrypted vault — your seed phrase and Kyber secret key, encrypted with a key derived from your password via PBKDF2 (600,000 iterations, SHA-256) and sealed with AES-256-GCM. The unencrypted secret only exists in volatile memory while the Wallet is unlocked, and is wiped on lock or automatically 10 minutes after you unlock.
  • Public wallet data — your Solana public address, your Kyber public key, and your derived vault identifier.
  • Cached UTXOs and balances — to render your portfolio instantly when you re-open the popup, the Wallet caches your UTXO list (token amounts, sender/receiver vault identifiers) in chrome.storage.local, encrypted at rest with AES-256-GCM under a key derived from your wallet secret that only exists in volatile memory while the Wallet is unlocked. The sealed snapshot is additionally bound (via AEAD associated data) to your account, network, and vault, so it cannot be decrypted under a different identity, and it cannot be read from the Chrome profile on disk while the Wallet is locked. As with any hot wallet, treat a device on which the Wallet is currently unlocked as sensitive, and avoid shared or untrusted machines.
  • Pending job state — the status of in-flight deposits, transfers, and withdrawals so the Wallet can reconnect to a job after you close the popup.
  • Token registry cache — a copy of the on-chain registered SPL token list.
  • Settings — your prover mode, network selection, your analytics and crash-reporting preference, and other UI preferences.

4. Network requests the Wallet makes

The Wallet does not phone home to Bonsol. The network endpoints it talks to are listed in the extension’s manifest under host_permissions and are limited to the following:

  • Solana RPC — the Solana JSON-RPC endpoint you configure (DevNet or Mainnet). Used to read on-chain state (your ledger, vaults, token accounts) and to submit transactions you authorize. The RPC operator may log standard request metadata such as your IP address; consider running your own RPC or routing through a privacy-preserving proxy if that is a concern.
  • QFire relay — Bonsol-operated relay used to publish ZK proofs and to forward node-signed attestation transactions to Solana. QFire receives the proof bytes and your sender vault identifier. Because the proof’s public journal commits to the receiver vault PDAs, the on-chain UTXO hashes you are spending, and (for withdrawals) the destination Solana wallet, token, and amount, QFire sees those values too — but all of them are also visible on the public Solana ledger by design. QFire does NOT receive your private keys, your seed phrase, or the cleartext token amounts and token types of vault-to-vault transfers; those remain encrypted in the on-chain UTXO payload, decryptable only by the receiver.
  • Remote prover (default) — by default, the proof inputs needed to generate your ZK proof are sent over TLS to a Bonsol-operated proving server. These inputs are derived from data you have decrypted in your browser’s memory and include: your wallet’s Kyber public key (which identifies your wallet to the prover), the decrypted contents of the UTXOs you are spending (token amounts and types), the receiver vault PDAs and decrypted token amounts of any transfers, and the destination Solana wallet, token, and amount of any withdrawal. Your password, your seed phrase, your Kyber secret key, and your encrypted vault are never sent. In the current build this means the proving server operator is technically a trusted third party with read access to your decrypted transaction inputs while a proof is being generated. The remote prover is being developed with hardware-attested execution (AMD SEV-SNP CPU + Nvidia GPU attestation) so that even Bonsol operators cannot read proof inputs in transit or at rest; hardware attestation is not yet enabled in the MVP build. Users who require zero trust in the proving operator can switch prover mode to “Local” in Settings (this requires separately installing the Sombra prover daemon and disables remote proving entirely).
  • Local prover daemon (advanced, opt-in) — if you separately download and install the Sombra prover daemon and switch prover mode in Settings, proofs are generated on your own machine. The Wallet talks to the daemon only via Chrome native messaging; nothing leaves your device for proof generation in this mode.
  • Analytics (PostHog) and crash reporting (Sentry) — contacted only while the analytics & crash-reporting toggle is enabled (it is on by default and can be turned off in Settings). These endpoints receive the anonymous usage and crash data described in Section 5, and never receive your keys, seed phrase, or the cleartext amounts, token types, or addresses of your transactions.

5. Optional analytics & crash reporting

To help us fix bugs and understand which features are used, the Wallet includes two optional telemetry streams: product analytics (PostHog) and crash reporting (Sentry). Both are enabled by default and are controlled by a single “Analytics & crash reports” switch in Settings. Turning it off stops all collection for both streams immediately.

  • Anonymous, no distinct ID. Both streams collect anonymous usage and stability data only. We do not assign or transmit a persistent user identifier, account, or device fingerprint that ties events back to you, and we do not attempt to re-identify you across sessions.
  • Analytics (PostHog). When enabled, the Wallet sends anonymous product-usage events — for example which screens are opened and whether common actions succeed or fail — so we can prioritize improvements.
  • Crash reporting (Sentry). When enabled, the Wallet sends anonymized error and crash diagnostics (such as the error type, a stack trace, and basic environment information like the extension version and browser) when something goes wrong.
  • What is never sent. Neither stream ever receives your seed phrase, password, private or Kyber secret keys, your encrypted vault, or the decrypted amounts, token types, or addresses of your transactions. Diagnostic payloads are scrubbed to avoid including this data.

PostHog and Sentry act as data processors on our behalf and are contacted only while the Analytics & crash reports toggle is enabled. See Section 9 for retention.

6. Cryptographic design

Sombra is built on post-quantum primitives. Asymmetric encryption uses Kyber-768 (NIST ML-KEM-768). Hashing uses SHA-256. Zero-knowledge proofs use RISC0 STARKs. No part of the protocol relies on elliptic curve cryptography for confidentiality. Solana account signing still uses Ed25519, which is a property of the Solana network, not the Sombra protocol.

Two distinct symmetric ciphers are used at different layers:

  • On-chain UTXO payloads are encrypted with ChaCha20-Poly1305. For each UTXO, the sender uses Kyber-768 to encapsulate a fresh 32-byte shared secret against the receiver vault’s Kyber public key; that shared secret is used directly as the ChaCha20-Poly1305 key. Only the receiver — who holds the matching Kyber secret key — can decapsulate the same secret and decrypt the payload.
  • The local encrypted vault (the file containing your seed phrase and Kyber secret key in browser storage) is sealed with AES-256-GCM, using a key derived from your password via PBKDF2 (600,000 iterations, SHA-256). See Section 3 for the full at-rest description.

What Sombra hides, and what it does not.Token amounts and token types of vault-to-vault transfers are encrypted on-chain and only the receiver can decrypt them. Vault identifiers are pseudonymous hashes of Kyber public keys, not tied to a real-world identity unless the user reveals their public key off-chain. What Sombra does not hide is the existence and timing of transactions, the sender and receiver vault identifiers (visible on the public Solana ledger), and the destination wallet, token, and amount of any withdrawal back to a regular Solana wallet (these have to be public so the SPL token program can execute the transfer). Anyone evaluating Sombra for a specific threat model should review this trade-off carefully.

Anonymity is not guaranteed. Even with on-chain payload encryption, your activity may be deanonymized through transaction timing and graph analysis, correlation with the destination wallets you withdraw to, the remote prover’s view of your inputs (see Section 4), or your own off-chain disclosures. Sombra reduces what is visible on-chain; it does not make you anonymous.

7. Permissions the extension requests

  • storage — to persist your encrypted vault, cached state, and settings on your device.
  • nativeMessaging — to communicate with the local Sombra prover daemon.
  • alarms — to schedule background checks on in-flight proof submissions so a stuck or slow proof can be detected and recovered even when the popup is closed.
  • host_permissions — limited to the Solana RPC, the QFire relay, the remote prover URL, and the analytics (PostHog) and crash-reporting (Sentry) endpoints used by the optional telemetry described in Section 5 (the Wallet uses the remote prover by default; the local daemon path uses native messaging instead, which doesn’t require an HTTPS host permission). No content scripts; the extension never reads or modifies any website you visit.

8. Marketing site (sombra.tech)

The marketing site uses Vercel hosting and Vercel Analytics for aggregate traffic measurement (page views, referrers, user-agent). Vercel Analytics is cookieless and does not build a cross-site profile of you. The waitlist form, when used, sends your email address to Formspree, which acts as a processor on our behalf for the sole purpose of contacting you about beta access. You can ask us to delete it at any time.

9. Data retention

  • Local device data — your encrypted vault, cached UTXOs, job state, and settings remain on your device until you delete the extension’s data or uninstall it. We never receive them and therefore never retain them.
  • Remote prover inputs — proof inputs sent to the Bonsol proving server are held only transiently in memory for the duration of proof generation and are not written to persistent storage.
  • QFire relay — proof bytes and sender vault identifiers are processed to publish your proof to Solana and are discarded after submission; the resulting transaction is, by design, public on the Solana ledger.
  • Solana RPC metadata — standard request metadata (including your IP address) may be logged by the RPC operator under their own retention policy, which we do not control.
  • Analytics & crash-reporting data — when the Analytics & crash reports toggle is enabled, anonymous usage events (PostHog) and crash diagnostics (Sentry) are retained by those processors under their standard retention policies. Because the data is anonymous and carries no distinct user identifier, it cannot be attributed back to you. Turning it off in Settings stops further collection from both streams.
  • Waitlist email — held by Formspree as our processor solely to contact you about beta access, and deleted on request or when the beta program ends.

10. Children

Sombra is not intended for users under 13 (or under 16 in the EU). We do not knowingly collect data from minors.

11. Changes to this policy

When this policy changes in a material way, we will update the date above and announce the change in the Wallet’s release notes. Continued use of the Wallet after a change constitutes acceptance of the updated policy.

12. Contact

Questions, deletion requests, or security disclosures: sombra@bonsol.org.