Two recent public statements question whether wallets built on Spark-based wallet infrastructure are actually self-custodial in practice, regardless of what the underlying protocol supports in theory: - grubles ([@notgrubles](https://x.com/notgrubles/status/2074624676978962867)): "no Spark wallet app implements unilateral exit... none of them... you fully trust a third party due to how wallets implement Spark support in practice." - Francis Pouliot, Bull Bitcoin ([@francispouliot_](https://x.com/francispouliot_/status/2074651604943245529)): "a Spark wallet is pretty much a custodial wallet unless you can actually exit unilaterally if the servers go down." We don't assign verdicts based on tweets. This issue tracks the apps that need an actual source review + hands-on test before any verdict changes. This is step 1 (the list); code review and testing are open items below, not yet done. ### Existing WalletScrutiny policy already covers this `_mobile/com.livingroomofsatoshi.wallet.md` reviewed exactly this question on 2026-05-09, when Wallet of Satoshi launched a Spark-based "Self-Custody Mode," and was kept at **custodial**: > self-custodial at WalletScrutiny means **exclusive user control**—the user alone can authorize > spends without any third-party co-signature or trust. WoS, even with Spark, doesn't offer this > because operators must co-sign off-chain transfers. Note this isn't because no exit mechanism exists at all — WoS's own entry documents a working (if community-built, "use at your own risk") recovery path, [BlitzWallet/spark-recover](https://github.com/BlitzWallet/spark-recover), that lets a user withdraw to L1 without the operator. The custodial verdict stands because the app's **normal** payment path is shared-signing (operator co-signs every off-chain transfer) — exclusive user control isn't the default, only an emergency-recovery fallback outside the app itself. That's the bar each app below needs to be measured against. ### Apps found using Spark-based wallet infrastructure (local `walletScrutinyCom` repo) Two different SDKs show up below — Breez SDK Spark and BuildOnSpark's own SDK — both built on the same underlying Spark protocol (2-of-2 shared-signing), but from different vendors. Noted per row. | App | wsId/appId | Current verdict | SDK | Notes | |---|---|---|---|---| | Wallet of Satoshi | `com.livingroomofsatoshi.wallet` | custodial (both) | Breez SDK Spark | Already reviewed for this exact question; kept custodial. Cites kphur (Spark creator), TheBlueMatt, NicolasDorier, conduition_io. | | Bringin | `xyz.bringin.client` | nosource (both) | Breez SDK Spark | Docs claim self-custodial. No source available to verify code-level exit behavior. | | Radar (Chat & Bitcoin) | `com.cakelabs.signal` | sourceavailable (iOS live; Android source public, not yet on Play) | Breez SDK Spark v0.14.0 | **Not on master** — lives only on branch `newApp/radarchat` (MR unmerged). `preferSparkOverLightning=true`. Source checked directly: `radar-labs/radar-android`'s `BreezSdkWrapper.kt` only calls `checkLightningAddressAvailable`, `deleteLightningAddress`, `getInfo`, `getLightningAddress`, `listFiatRates`, `listPayments`, `receivePayment`, `sendPayment`, `registerLightningAddress` — no exit/withdraw/unilateral-exit call anywhere in the client code, even though the underlying `breez/spark-sdk` Rust core does expose `unilateral_exit()` (`crates/spark-wallet/src/wallet.rs:1344`, takes `leaf_ids`). Same structural gap as WoS. | | Split (Split Rewards) | `com.splitloyalty.app.Split-Rewards` | nosource | Spark (unspecified SDK) | Markets itself as "self-custodial Bitcoin Lightning (Spark) wallet." No source to check. | | Guap | `com.useguap.android.rn` / `com.useguap.ios.rn` | custodial (both) | Spark (unspecified SDK) | Already classified custodial — Spark noted in evidence but doesn't change verdict. Keys said to be "stored client-side," infra via Privy. | | BlitzWallet | `com.blitzwallet` | sourceavailable | `@buildonspark/spark-sdk` | Version varies by local-notes snapshot: `^0.4.3` in an earlier findings file, `^0.6.7` in the more recent one (a version-mismatch correction is noted in between) — cite the current `package.json` directly rather than either note before publishing. Site entry body doesn't mention Spark at all yet — separate documentation gap regardless of the custody question. | | Trustless BTC | `com.btc.trustless` | wip (both) | `@breeztech/breez-sdk-spark-react-native` | `0.12.2` in the v2.0.2-scoped notes, `0.12.3` in the later/main build instructions — version-dependent, check current `package.json`. Local forensic notes already flag: "Lightning is semi-custodial. Breez SDK Spark means Lightning funds go through Breez's infrastructure. Relevant to the custodial verdict." Not yet reflected in the site body. | ### Open items (not yet done) - [x] For each sourceavailable/wip entry (Radar, BlitzWallet, Trustless BTC): confirm via source whether the client code ever calls an exit/withdraw function, or only routine send/receive (same check already done for Radar). - [x] For nosource entries (Bringin, Split): re-check once source ships. - [x] Hands-on test: for at least one app where source review shows no exit call, actually attempt self-custody/recovery (e.g. [`BlitzWallet/spark-recover`](https://github.com/BlitzWallet/spark-recover)) to confirm whether unilateral exit is achievable in practice for that specific app, not just in theory. - [x] Decide, per app, whether the WoS precedent should override any "self-custodial" language in that app's own WS description (Radar's current App Description calls it self-custodial). - [x] Radar's MR (`newApp/radarchat`) should stay unmerged until its Android app ships on Play Store, so it can be tested directly. ### References - https://x.com/notgrubles/status/2074624676978962867 - https://x.com/francispouliot_/status/2074651604943245529 - `_mobile/com.livingroomofsatoshi.wallet.md` (2025-10-09 Self-Custody Mode section — governing precedent) - Spark trust model: https://docs.spark.money/spark/trust-model - Breez SDK Spark: https://sdk-doc-spark.breez.technology/