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
30th June 2026
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.Application build
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
Radar is a messaging app built as a fork of Signal (Android and iOS), adding Bitcoin payments alongside Signal’s end-to-end encrypted chat. Bitcoin functionality runs on the Breez SDK Spark (v0.14.0) — Spark is a Bitcoin “layer 2” system, similar in spirit to the Lightning Network, that lets payments settle instantly without every transaction hitting the Bitcoin blockchain directly. Radar’s code is public and it implements a recovery-phrase backup system (details below), but — as explained in this review — the app does not give users a way to move their funds to normal on-chain Bitcoin without the Spark service infrastructure it depends on cooperating, which is why this entry is rated custodial rather than self-custodial, despite Radar’s own marketing describing it that way. Both the Android (radar-labs/radar-android) and iOS (radar-labs/Radar) repositories are public on GitHub under the AGPL-3.0 license; the iOS app is live on the App Store while Android is not yet published to Google Play (available via GitHub Releases / Obtainium instead).
Testing and Analysis
We do not have access to an iPhone device during testing, and the Google Play version has not yet been released. This review is based on reading Radar’s public source code directly for both platforms — iOS (repository: radar-labs/Radar, commit d997428ba3), which is what this WS listing tracks, and Android (repository: radar-labs/radar-android, commit 4a6e9f8f2a), reviewed alongside as cross-platform confirmation since both share the same underlying custody model — plus the public source of the Breez SDK both depend on (repository: breez/spark-sdk, tag 0.14.0, the exact version pinned in both apps’ dependency files). Key technical claims below cite the exact line of code they’re based on, so they can be checked independently; broader statements (e.g. that a repo-wide search or an issue-tracker search turned up nothing) describe the search performed rather than linking to a single line, since there’s no specific line a “no result” claim can point to.
Background: what “self-custodial” requires, and two different ways to “get your money out”
WalletScrutiny’s bar for a wallet to count as self-custodial is exclusive user control: the user alone must be able to authorize spending their funds, with no other party’s cooperation required. This same bar was already applied to Wallet of Satoshi’s Spark-based “Self-Custody Mode”, which was kept at a custodial verdict for the same underlying reason explained here.
Spark, the Bitcoin layer-2 system Radar uses, works by having the user’s own keys plus a separate Spark service/operator infrastructure jointly authorize normal transfers — the user alone cannot move funds without that infrastructure’s cooperation. Neither Radar’s Android nor iOS app overrides this infrastructure with anything Radar-operated: both simply use the Breez SDK’s default configuration, which points at Lightspark’s own service (https://api.lightspark.com, confirmed in the SDK’s default configuration) — so the cooperating party here is Lightspark/Breez infrastructure, not a server Radar Chat Inc. itself runs. This creates two, very different ways a user could move Spark funds to a normal on-chain Bitcoin address:
- Cooperative withdrawal: the user asks to withdraw, and the Spark service/operator infrastructure cooperates to help build and send the transaction. This is the “normal” way to get money out of Spark, but it only works as long as that infrastructure is running and willing to help.
- Unilateral exit: the user recovers their funds to a normal Bitcoin address entirely on their own, using pre-signed exit transactions, with no cooperation needed from any Spark service/operator at all — even if that infrastructure (or Radar itself) disappeared or refused to help. This is the feature that would actually satisfy WalletScrutiny’s “exclusive user control” bar.
What we found: neither path is available to a Radar user today
This app’s WalletScrutiny listing is for the iOS release (Android has not shipped to Google Play yet), so the findings below cite Radar’s iOS source (radar-labs/Radar, commit d997428ba3) as the primary evidence. Radar’s separate Android source (radar-labs/radar-android, commit 4a6e9f8f2a) was also reviewed and reaches the same conclusion through different code, cited alongside as cross-platform confirmation.
Cooperative withdrawal exists in the SDK, but Radar’s own code never uses it, on either platform. The Breez SDK Spark library does support cooperative on-chain withdrawal: its send_payment/prepare_send_payment functions, when given a Bitcoin address as the destination, call spark_wallet.withdraw(...), which in turn calls coop_exit_service.coop_exit(...) — a real send-to-Bitcoin-address feature, provided the Spark service cooperates. Radar’s own outgoing-payment code never reaches this:
- iOS: the app’s
PreparedTransactiontype (PaymentsImpl.swift#L1660) only has two cases,.lnurlPayand.bolt11— there is no Bitcoin-address case at all. The code that actually sends a payment (PaymentsProcessor.swift#L626-635) exhaustively handles only those two cases; elsewhere inPaymentsImpl.swift(e.g. line 1674), a Bitcoin-address-typed SDK response reaching that same.bolt11case is explicitly treated as an unexpected error (owsFailDebug("Unexpected payment method for BOLT11 invoice.")) rather than a valid outcome. - Android: the
sendPayment()function inBreezSdkWrapper.ktonly calls a different pair of functions meant for paying Lightning addresses (prepareLnurlPay/lnurlPay), and its own internal helper explicitly rejects a Bitcoin address as a destination (throwing an error) before the request would ever reach the SDK’s withdrawal function. Android’s only other on-chain-related call,getOnchainAddress()(line 220), only requests an address to receive Bitcoin into the wallet — the opposite direction, and not a withdrawal.
Unilateral exit is not available at all — not because Radar chose not to build it, but because the version of the SDK Radar uses doesn’t offer it to the app in the first place. The underlying Spark protocol does have a real unilateral_exit() function (crates/spark-wallet/src/wallet.rs#L1293), but it lives inside an internal piece of the SDK that is never made callable from the app-facing (Kotlin/Swift) side of the library at version 0.14.0 — this applies identically to both platforms, since they share the same underlying Rust SDK and its UniFFI-generated bindings. We checked every function the SDK does make available to apps (there are about 30, covering payments, contacts, deposits, lightning addresses, and wallet sync) and confirmed unilateral_exit is not among them. This means that even if Radar’s developers wanted to add a “recover my funds independently” button today, the tool to build it with doesn’t currently exist in the SDK version they depend on.
We also searched Radar’s entire codebase (not just the payments code) for any mention of exiting, withdrawing, or recovering funds independently, checked every string shown in the app’s UI, and searched the project’s GitHub issue tracker — and found nothing describing such a feature, planned or otherwise.
The recovery phrase: what it actually proves, and what it doesn’t
Radar does implement a recovery-phrase backup flow on both platforms — this part of the app is worth explaining clearly, because it’s easy to mistake for the unilateral-exit capability described above (it isn’t the same thing), and because the two platforms don’t implement it identically.
Android generates 16 bytes of randomness on the phone (Entropy.generateNew(), Entropy.java#L26) and turns it into a standard 12-word BIP-39 recovery phrase, checking its own round trip at generation time — the code converts entropy to a mnemonic and immediately decodes it back, asserting the bytes match (Entropy.asMnemonic(), Entropy.java#L49). Entering those 12 words back in restores the wallet by converting the phrase back into the original random bytes (PaymentsRecoveryPhraseRepository.java#L27, PaymentsValues.kt#L367) — a standard, reversible BIP-39 operation.
iOS generates the phrase the same standard way (16 bytes of randomness, Payments+SSK.swift#L241), for both the phrase shown to the user (PaymentsImpl.passphrase(forPaymentsEntropy:), PaymentsImpl.swift#L401-405) and for initializing the SDK (BreezSdkExt.build, BreezSdkExt.swift#L11-17 — that function’s own comment is stale, still describing “32 bytes” and a “24-word mnemonic” against the current 16-byte/12-word constant; creation itself isn’t affected). New wallets use 12 words, while older wallets created before a prior update may still have a 24-word phrase on file (supportedPassphraseWordCounts = [12, 24], Payments+SSK.swift#L113).
Restoring an entered phrase on iOS is broken, and confirmable from source alone. When a user re-enters a phrase to restore a wallet, iOS does not decode it back into the original random bytes the way Android does — it runs the entered words through MnemonicSwift.Mnemonic.deterministicSeedBytes(...) (PaymentsImpl.swift#L412-416), which we traced to a PBKDF2-SHA512 computation — a different, standard BIP-39 operation that derives a 64-byte wallet seed, not the original entropy bits. That 64-byte value is never a valid length: Radar’s own entropy field only accepts 16 or 32 bytes (supportedPaymentsEntropyLengths, Payments+SSK.swift#L245). That length check lives in PaymentsState.build, PaymentsHelper.swift#L99-113, which silently falls back to .disabled instead of storing the oversized value — so the Breez SDK is never actually initialized with it. But the restore flow’s own success check doesn’t notice: enablePayments(withPaymentsEntropy:), PaymentsHelperImpl.swift#L129-143 returns true regardless of whether the length check passed, so the restore-complete screen, PaymentsRestoreWalletCompleteViewController.swift#L162-181 tells the user the restore worked while payments quietly stay disabled. This is a static-source finding, not a guess: the 12 words are still a standard, valid BIP-39 backup of the entropy — the bug is that this specific iOS build cannot correctly consume its own backup phrase to restore itself, and its UI does not report the failure.
In plain language, here’s the important distinction that holds regardless of that iOS detail: even in the best case, where the backup phrase does restore the wallet correctly, that only gets you back into your same wallet using Radar itself, or another app specifically built to speak the Spark protocol the same way. It proves the funds are “yours” in the sense of restoring access to them — but it is not, by itself, a way to move your bitcoin to a normal Bitcoin address if the Spark service infrastructure Radar depends on ever goes offline, shuts down, or refuses to cooperate. Restoring your wallet with a backup phrase still requires software that understands Spark, and that software still needs to talk to a Spark service to figure out the current state of your funds and actually build a valid withdrawal — exactly the “cooperative” arrangement described above, which stops working the moment the cooperating service disappears. Actually getting bitcoin out independently, without any service’s help, is what “unilateral exit” would provide — and as shown above, that capability doesn’t exist in this app today.
Conclusion
Radar’s source code is genuinely public (AGPL-3.0, both platforms), and it has a recovery-phrase system: on Android, the entropy-to-mnemonic-to-entropy round trip is clearly implemented and self-checked in the code; on iOS, the restore path is confirmed broken from source alone (see above) — it derives a 64-byte value that fails the app’s own entropy-length check, and the app reports success anyway. Regardless of that detail, WalletScrutiny’s self-custodial bar requires that a user can move their funds on their own, with nobody else’s permission — and on the evidence gathered here, Radar provides no way to do that on either platform: not a cooperative withdrawal (the app never calls the SDK function that would allow it), and not a unilateral exit (the SDK version Radar depends on doesn’t expose that capability to the app at all). This matches the reasoning already applied to Wallet of Satoshi’s own Spark integration. This app is rated custodial.
Product page updated by Daniel Andrei R. Garcia
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.