Our wallet review process
We examine wallets starting at the code level and continue all the way up to the finished app that lives on your device. Provided below is an outline of each of these steps along with security tips for you and general test results.
Released
29th September 2025
Custody
Custodial!
As part of our Methodology, we ask: Does the product allow self-custody?
The answer is "no". Therefore we marked it as "Custodial: The provider holds the keys".
Read more
Source code
Public on github
Passed 4 of 7 tests
We answered the following questions in this order:
We stopped asking questions after we encountered a failed answer.
The answer is "yes".
If the answer were "no", we would mark it as "Fake" and the following would apply:
The answer is "no". We marked it as "Fake".
We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "Fake" and the following would apply:
The bigger wallets often get imitated by scammers that abuse the reputation of the product by imitating its name, logo or both.
Imitating a competitor is a huge red flag and we urge you to not put any money into this product!
The answer is "yes".
If the answer were "no", we would mark it as "Not a wallet" and the following would apply:
The answer is "no". We marked it as "Not a wallet".
We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "Not a wallet" and the following would apply:
If it’s called “wallet” but is actually only a portfolio tracker, we don’t look any deeper, assuming it is not meant to control funds. What has no funds, can’t lose your coins. It might still leak your financial history!
If you can buy Bitcoins with this app but only into another wallet, it’s not a wallet itself.
The answer is "yes".
If the answer were "no", we would mark it as "A wallet but not for Bitcoin" and the following would apply:
The answer is "no". We marked it as "A wallet but not for Bitcoin".
We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "A wallet but not for Bitcoin" and the following would apply:
At this point we only look into wallets that at least also support BTC.
The answer is "yes".
If the answer were "no", we would mark it as "Can't send or receive bitcoins" and the following would apply:
The answer is "no". We marked it as "Can't send or receive bitcoins".
We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "Can't send or receive bitcoins" and the following would apply:
If it is for holding BTC but you can’t actually send or receive them with this product then it doesn’t function like a wallet for BTC but you might still be using it to hold your bitcoins with the intention to convert back to fiat when you “cash out”.
All products in this category are custodial and thus funds are at the mercy of the provider.
The product cannot be independently verified. If the provider puts your funds at risk on purpose or by accident, you will probably not know about the issue before people start losing money. If the provider is more criminally inclined he might have collected all the backups of all the wallets, ready to be emptied at the press of a button. The product might have a formidable track record but out of distress or change in management turns out to be evil from some point on, with nobody outside ever knowing before it is too late.
The answer is "yes".
If the answer were "no", we would mark it as "Custodial: The provider holds the keys" and the following would apply:
The answer is "no". We marked it as "Custodial: The provider holds the keys".
We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "Custodial: The provider holds the keys" and the following would apply:
A custodial service is a service where the funds are held by a third party like the provider. The custodial service can at any point steal all the funds of all the users at their discretion. Our investigations stop there.
Some services might claim their setup is super secure, that they don’t actually have access to the funds, or that the access is shared between multiple parties. For our evaluation of it being a wallet, these details are irrelevant. They might be a trustworthy Bitcoin bank and they might be a better fit for certain users than being your own bank but our investigation still stops there as we are only interested in wallets.
Products that claim to be non-custodial but feature custodial accounts without very clearly marking those as custodial are also considered “custodial” as a whole to avoid misguiding users that follow our assessment.
We have to acknowledge that a huge majority of Bitcoiners are currently using custodial Bitcoin banks. If you do, please:
- Do your own research if the provider is trust-worthy!
- Check if you know at least enough about them so you can sue them when you have to!
- Check if the provider is under a jurisdiction that will allow them to release your funds when you need them?
- Check if the provider is taking security measures proportional to the amount of funds secured? If they have a million users and don’t use cold storage, that hot wallet is a million times more valuable for hackers to attack. A million times more effort will be taken by hackers to infiltrate their security systems.
The answer is "yes".
If the answer were "no", we would mark it as "No source for current release found" and the following would apply:
The answer is "no". We marked it as "No source for current release found".
We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "No source for current release found" and the following would apply:
A wallet that claims to not give the provider the means to steal the users’ funds might actually be lying. In the spirit of “Don’t trust - verify!” you don’t want to take the provider at his word, but trust that people hunting for fame and bug bounties could actually find flaws and back-doors in the wallet so the provider doesn’t dare to put these in.
Back-doors and flaws are frequently found in closed source products but some remain hidden for years. And even in open source security software there might be catastrophic flaws undiscovered for years.
An evil wallet provider would certainly prefer not to publish the code, as hiding it makes audits orders of magnitude harder.
For your security, you thus want the code to be available for review.
If the wallet provider doesn’t share up to date code, our analysis stops there as the wallet could steal your funds at any time, and there is no protection except the provider’s word.
“Up to date” strictly means that any instance of the product being updated without the source code being updated counts as closed source. This puts the burden on the provider to always first release the source code before releasing the product’s update. This paragraph is a clarification to our rules following a little poll.
We are not concerned about the license as long as it allows us to perform our analysis. For a security audit, it is not necessary that the provider allows others to use their code for a competing wallet. You should still prefer actual open source licenses as a competing wallet won’t use the code without giving it careful scrutiny.
The product cannot be independently verified. If the provider puts your funds at risk on purpose or by accident, you will probably not know about the issue before people start losing money. If the provider is more criminally inclined he might have collected all the backups of all the wallets, ready to be emptied at the press of a button. The product might have a formidable track record but out of distress or change in management turns out to be evil from some point on, with nobody outside ever knowing before it is too late.Distribution
Build Verifications
If you have a binary for a version that doesn't appear on the list, you can dropselect the file here to register it so somebody can verify its reproducibility:
App Description
Blitz Wallet is an open-source Bitcoin and Lightning wallet.
It supports on-chain Bitcoin and Lightning transactions.
Updated Verdict
Verdict updated to custodial (see rationale below) — pending Luis/team review of this MR.
Prompted by GitLab issue #947, tracking public claims that Spark-based wallets do not implement unilateral exit in practice. Governing precedent: Wallet of Satoshi’s Spark “Self-Custody Mode” was reviewed for the same question and kept at custodial, because normal Spark transfers require the operator’s co-signature — see _mobile/com.livingroomofsatoshi.wallet.md, lines 103-105. Blitz Wallet is reviewed below against that same bar.
All code citations below are pinned to two commits: Blitz Wallet Android at BlitzWallet/BlitzWallet@546fcfc8, and its @buildonspark/spark-sdk dependency at the matching source commit buildonspark/spark@87f3b357. package.json declares ^0.8.5; the yarn lockfile resolves that to the exact published version 0.8.5.
1. Does the app support (sending/receiving) on-chain BTC?
Yes, but on-chain receive is not the default action. The home screen has two separate buttons: the main “Receive” (down-arrow) button opens a Spark-native menu (Quick Pay/username, Create Invoice, Create Pool, Add Contact) — handleReceive. A separate “Deposit” button opens a different menu that does include “Deposit Bitcoin / Receive via on-chain address” — handleDeposit, on-chain option label.
That “on-chain” address is not a locally-derived wallet address — selecting it calls the SDK’s wallet.getStaticDepositAddress() (app call site: app/functions/spark/index.js#L467-L482), which in turn requests the address from the Spark coordinator via generateStaticDepositAddress(), a live RPC (generate_static_deposit_address) that returns a coordinator-signed proof. The address cannot be generated offline.
On-chain sending works through sendSparkBitcoinPayment(), which calls the SDK’s wallet.withdraw(). Reading the SDK implementation, withdraw() is explicitly a Cooperative Exit Flow — it calls the Spark Service Provider’s requestCoopExit/completeCoopExit endpoints to produce the on-chain payout transaction. Generating the app’s on-chain receive address and completing on-chain withdrawals both depend on Spark server-side infrastructure.
2. Does the app allow the export of BIP-39 seed phrases?
Yes. The app exports a standard 12-word BIP-39 mnemonic — confirmed via its @scure/bip39 usage in app/functions/seed.js#L1-L25 and app/functions/isValidMnemonic.js#L1-L2 — but Spark balances depend on Spark-specific BIP-32 derivation paths on top of that mnemonic (see Q3). The Settings screen displays the live wallet’s mnemonic in full, with copy-to-clipboard and a SeedQR export view — app/components/admin/homeComponents/settingsContent/seedPhrasePage.js#L1-L34, matching the project’s own claim: README.md, “Self-custodial recovery”.
3. Are the seed phrases importable to wallets outside of the Spark SDK ecosystem?
The words themselves are valid input to any standard BIP-39 wallet, but generic wallets will not find or use the Spark balance by default, because they do not implement Spark’s derivation scheme or off-chain state model. The SDK derives every functional key (identity, signing, deposit, static deposit, HTLC preimage) under a custom, Spark-specific derivation path — m/8797555'/{accountNumber}'/{0-4}' — not any registered BIP44/49/84/86 purpose code a general-purpose wallet would try by default. See DefaultSparkKeysGenerator.deriveKeysFromSeed().
Practical effect: importing a Blitz Wallet seed phrase into a standard wallet (e.g. Electrum) is expected to derive an unrelated, empty set of keys under that wallet’s own default path, rather than surfacing any Blitz/Spark balance. This is expected because generic wallets do not implement Spark’s derivation scheme or off-chain state model — it does not by itself confirm or rule out unilateral exit, which is a separate question addressed next.
4. Is it possible for users to commence unilateral exit?
No path was found in Blitz Wallet’s own client code. Notably, unlike some other Spark-SDK wallets reviewed under #947, @buildonspark/spark-sdk 0.8.5 does publicly export real, operator-independent unilateral-exit machinery — buildUnilateralExitChain() and constructUnilateralExitFeeBumpPackages() — callable using leaf data (wallet.getLeaves()) the app already fetches, with no SSP cooperation required to construct the exit chain.
An exhaustive, file-by-file audit of every @buildonspark/spark-sdk call in the Blitz Wallet app (34 distinct SDK methods across the 5 files that import the package) found no call to either function, or to any other export of unilateral-exit.ts. The app’s only on-chain withdrawal path is the cooperative wallet.withdraw() described in Q1. No UI element, settings screen, or documentation in the repository references “unilateral exit” or an operator-independent recovery flow (grep -n -iE "unilateral" across the full repo: zero hits).
Blitz Wallet also operates its own standalone recovery tool, BlitzWallet/spark-recover, hosted at recover.blitzwalletapp.com and self-described as “Self-custodial. Stateless. Trustless. No third parties.”. Reviewed at commit eddcd347, pinned to @buildonspark/spark-sdk@^0.6.0: it calls the same cooperative wallet.transfer() and wallet.withdraw() methods as the main app — it is a second client for the same operator-dependent operations, not an independent exit mechanism. It is useful if the main app becomes unavailable while Spark’s operators are still online and cooperating, but it does not answer what happens if they are not.
Rationale for the verdict change
Under the WoS precedent — self-custodial requires exclusive user control as the normal path, not just a theoretical capability elsewhere in the dependency tree — Blitz Wallet’s shipped app does not meet that bar today: the app’s Spark send/withdraw paths, on-chain receive-address generation, and recovery tool all depend on Spark operator/coordinator cooperation. The verdict above has been updated from sourceavailable to custodial accordingly, consistent with the WoS/#947 precedent, pending team review of this MR.
Analysis (Previous)
We installed the app and created a BTC wallet with send/receive functions. We found its repository and confirm that it is source-available.
Blitz Wallet is a React Native application that allows users to interact with the Bitcoin Lighting Network in a self-custodial way.
Source: GitHub README
Blitz is released under the terms of the Apache 2.0 license. See LICENSE for more information.
Source: License
Product page updated by Daniel Andrei R. Garcia
⚠️ Liquid Network Integration
Liquid Bitcoin is NOT Bitcoin. L-BTC is held by a federation of companies. If a quorum of federation members collude or are compelled, they can seize all L-BTC. If Blockstream alone fails to rotate keys on schedule, they gain unilateral control. Only use Liquid for amounts you'd trust to a corporate consortium.
Do your own research
In addition to reading our analysis, it is important to do your own checks. Before transferring any bitcoin to your wallet, look up reviews for the wallet you want to use. They should be easy to find. If they aren't, that itself is a reason to be extra careful.