Wallet Logo

Trustless

Google Play App Store Website

Latest release found by WalletScrutiny: 2.0.0 / 3.1.1

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.

Developer

pechen987 (Android)
Igor Kruglov (iPhone)

Website X GitHub

Released

3rd February 2026

Custody

Custodial!

But This product was removed from the platform.

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.

Is this product the original?

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 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.
Is it a wallet?

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.

Is it for bitcoins?

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.

Can it send and receive bitcoins?

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.
Does the product allow self-custody?

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 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.
Is the source code publicly available?

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.
Is the decompiled binary legible?

The answer is "yes".
If the answer were "no", we would mark it as "Obfuscated" and the following would apply:

The answer is "no". We marked it as "Obfuscated".

We did not ask this question because we failed at a previous question.
If the answer were "no", we would mark it as "Obfuscated" and the following would apply:

When compiling source code to binary, usually a lot of meta information is retained. A variable storing a masterseed would usually still be called masterseed, so an auditor could inspect what happens to the masterseed. Does it get sent to some server? But obfuscation would rename it for example to _t12, making it harder to find what the product is doing with the masterseed.

In benign cases, code symbols are replaced by short strings to make the binary smaller but for the sake of transparency this should not be done for non-reproducible Bitcoin wallets. (Reproducible wallets could obfuscate the binary for size improvements as the reproducibility would assure the link between code and binary.)

Especially in the public source cases, obfuscation is a red flag. If the code is public, why obfuscate it?

As obfuscation is such a red flag when looking for transparency, we do also sometimes inspect the binaries of closed source apps.

As looking for code obfuscation is a more involved task, we do not inspect many apps but if we see other red flags, we might test this to then put the product into this red-flag category.

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.

This product was removed from the platform.

Distribution

Google Play Website

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:

Drop binary file to verify

or
Learn more

Platform notes

On the Google Play Store, there are many apps that have Bitcoin in their name or description but don’t allow the user to use Bitcoin or they don’t look like Bitcoin wallets but turn out to be. We run our tests and document our findings.

App Description

Trustless is an open-source, Bitcoin-only mobile wallet with two pockets in one app: a regular on-chain Bitcoin wallet, and a Lightning balance that runs on Spark (via Breez’s SDK). Its README describes it as “a fully open-source, non-custodial, privacy-focused, Bitcoin-only mobile wallet” with “Non-custodial Lightning: … You can top-up and withdraw from your lighning balance at anytime.”

Analysis

This review was done as part of issue #947, which tracks whether Spark-based wallets actually let users exit to on-chain Bitcoin without anyone’s permission. Partway through, we belatedly confirmed that the Android app has been removed from Google Play (the store page returns 404); iOS is the only current store-listed version (3.0.1, 1 rating), though a sideloadable APK remains on the project’s GitHub releases page. By then the source review was already complete, so we are publishing the findings anyway — they matter for the broader Spark custody question regardless of this app’s listing status.

1. Can you send and receive on-chain Bitcoin? Yes, properly. The on-chain pocket is a real Bitcoin wallet: your keys are made on your phone using the industry-standard recipe (BIP-84, the same one Electrum and Sparrow use), transactions are signed on your phone, and it talks to Electrum servers for balances and broadcasting — public ones by default, or your own node if you set one. No company sits in the middle of your on-chain money.

2. Can you export your seed phrase? Yes. There’s a screen that shows your 12 words, plus a QR export, and a restore screen to bring a wallet back.

3. If Trustless disappeared tomorrow, could you recover your money with just the seed phrase in another wallet? Half yes, half no. Your on-chain money: yes — type the 12 words into Electrum or Sparrow and your coins are there, because Trustless uses the standard key recipe. Your Lightning money: no — that balance lives inside Spark’s off-chain system, and a normal wallet can’t see it. You’d need Spark-aware software and Spark’s servers still running and willing to cooperate.

4. Can you force your Lightning money back on-chain if Spark’s operators go offline or refuse? No. The app does have a real “Withdraw to on-chain” button — more than most Spark wallets offer — but under the hood that button politely asks the service provider (Lightspark, by default — not Breez, as it turns out) to help build the exit transaction. If they don’t cooperate, there’s no plan B: the emergency “unilateral exit” that Spark’s design brags about exists deep in the code, but neither the app nor the SDK version it uses gives anyone a way to press it. There’s also no separate rescue tool (BlitzWallet publishes one, but note that even theirs still needs the operators’ cooperation — it is not a unilateral fallback either).

Bottom line: the app’s claim of being “non-custodial” is true for your on-chain pocket and oversold for the Lightning pocket. On-chain, you’re in full control. On Lightning, your money’s safety ultimately depends on Spark’s operators staying online and cooperative — the same pattern that drove the Wallet of Satoshi decision. One footnote: a reproducibility check of the GitHub release APK (the Play version was already gone) found that the JavaScript bundle, Android bytecode, and assets all matched the source exactly, with differences confined to natively-compiled libraries — possibly caused by build-environment differences, though the shipped binaries haven’t been fully reproduced from source yet.

Verdict: custodial. The on-chain pocket is genuinely self-custodial — a user can always export the seed and recover their BTC in any standard wallet — but that does not create an exception under WalletScrutiny’s written policy: “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.” Trustless explicitly markets its Lightning pocket as “non-custodial,” while this review shows moving that balance depends on third-party cooperation — the same limitation that kept Wallet of Satoshi’s Spark mode at custodial. Since the Android app is removed from Google Play and the iOS listing has almost no users, we are not investing in further hands-on testing unless something materially changes.

Technical Analysis

Everything below backs the plain-language answers above with exact code citations. 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. Trustless is measured against that same bar.

Scope — source-level, not binary-level. The primary review is pinned to two commits: Trustless at release tag 2.0.2 (266a2de4, the release examined by reproducibility issue #156) and its Breez SDK dependency at the source tag matching the lockfile resolution: breez/spark-sdk@0.12.2 (40e3cbe2). package.json declares the compatible range ^0.12.2; the lockfile pins the resolved version to 0.12.2, whose integrity hash matches the npm-published tarball (verifiable with npm pack @breeztech/breez-sdk-spark-react-native@0.12.2).

For precision, the versions in circulation are: the last Google Play version was 2.0.0 (before removal); the newest sideloadable GitHub release APK is 3.0.0 (2026-06-16); reproducibility issue #156 examined the older GitHub 2.0.2 APK; and the current iOS App Store release is 3.0.1. The custody-relevant facts were checked at each newer tag as well:

  • Tag 2.0.0 (462be317, the last Google Play version): lockfile resolves the SDK to 0.12.2; the withdrawal feature uses the same prepareSendPayment/sendPayment Bitcoin-address path (WalletContext.tsx#L616, #L678); a repo-wide grep for unilateral returns zero hits.
  • Tag 3.0.0 (753a5bfc, the newest Android APK): lockfile resolves the SDK to 0.12.3; the withdrawal feature uses the identical prepareSendPayment/sendPayment Bitcoin-address path (WalletContext.tsx#L640, #L702-L709); a repo-wide grep for unilateral returns zero hits.
  • Tag 3.0.1 (70341693, created 2026-06-19 — the same day as Apple’s 3.0.1 release; iOS builds from the same shared React Native source via Expo): same checks, same results (WalletContext.tsx#L640, #L702-L709, button at WalletScreen.tsx#L336).

The findings below therefore apply to every version in circulation: the last Play release (2.0.0-era source), the #156-examined 2.0.2, the newest Android APK (3.0.0), and the current iOS release (3.0.1). Neither the App Store binary nor the GitHub APKs have been fully reproduced from their tags (Expo generates the native projects at build time; see the #156 note below), so these remain source-level claims.

On the Android binary: a reproducibility check of the GitHub release v2.0.2 APK (the app was already gone from Google Play) found classes*.dex, AndroidManifest.xml, the JS bundle, and all assets byte-identical to a rebuild from this source; the 37 differences are confined to natively-compiled .so libraries (nine libraries across four ABIs, including the Breez SDK’s) plus resources.arsc — possibly caused by build-environment differences. Since all of the app-level custody wiring audited below lives in the byte-matching JS bundle, and the native SDK layer’s exposed API contains no unilateral-exit method at any nearby version, the native-library mismatch is a reproducibility concern rather than a custody one — but strictly, the shipped binaries have not been fully byte-verified against source.

1. On-chain BTC support

Unlike the other Spark-based wallets reviewed under #947, Trustless has a genuinely local on-chain wallet alongside its Spark-based Lightning balance. On-chain receive addresses are derived on-device under the standard BIP-84 path m/84'/0'/0' (src/constants/network.ts#L7, derivation), transactions are built and signed locally with bitcoinjs-lib (createAndSignTransaction, PSBT construction), and balances, history, UTXOs, and broadcasting go through the Electrum protocol (src/services/electrum.ts, a from-scratch TLS Electrum client; consumed by src/services/bitcoin.ts) — defaulting to public peers electrum.blockstream.info:50002 and electrum.emzy.de:50002, with a user-configurable custom server. mempool.space’s REST API is used for fee estimates (with Electrum as the fallback estimator), and the explorer URLs open transaction/address pages in the browser. No coordinator is involved in generating on-chain addresses or signing on-chain transactions.

The Lightning balance is different: it runs on the Breez SDK’s Spark integration (breezSdk.connect, gated on a Breez API key). Its “top-up” on-chain address is requested through the SDK (receivePayment with ReceivePaymentMethod.BitcoinAddress), and withdrawing the Lightning balance to L1 goes through the SDK’s send-payment path (§4).

2. Seed phrase export

The app generates a standard BIP-39 mnemonic, stores it in the OS keychain (com.btc.trustless.mnemonic service), and exposes it to the user via dedicated screens: ShowMnemonicScreen, ShowMnemonicQRScreen, and VerifyMnemonicScreen, backed by getMnemonicForWallet. A RecoverWalletScreen restores from the same mnemonic.

3. Seed portability outside the Spark ecosystem

  • The on-chain balance: yes, genuinely. Because the on-chain side uses the standard BIP-84 derivation path (§1), importing the seed into any mainstream wallet that speaks BIP-84 (Electrum, Sparrow, BlueWallet, …) will locate and spend those funds with no Trustless- or Spark-specific knowledge. This is a real, exercisable independence guarantee for the on-chain balance.
  • The Lightning/Spark balance: no. The same mnemonic is also fed to the Breez SDK (breezSdk.Seed.Mnemonic.new), but that balance lives in Spark’s off-chain leaf state, maintained by the Spark operator infrastructure — a generic BIP-39 wallet has no way to see or spend it. Recovering this balance requires Spark-aware software connecting to the same operator network.

4. Unilateral exit

Trustless does ship a real, user-reachable on-chain withdrawal for the Lightning balance — a “Withdraw to on-chain” screen linked from the main wallet screen (navigation entry, button, screen calls) — which is further than most Spark wallets have gone. But tracing it end-to-end shows it is a cooperative exit, not a unilateral one:

  • The app calls the SDK’s prepareSendPayment / sendPayment with a Bitcoin-address destination.
  • In the SDK’s Rust core at the pinned tag, that destination routes to fetch_coop_exit_fee_quote at prepare time and send_bitcoin_address() → spark_wallet.withdraw() at send time.
  • withdraw() performs the SDK’s cooperative exit — its own code comment reads, verbatim, “Perform the cooperative exit with the SSP”. The SSP (Spark Service Provider) in the SDK’s default configuration — which Trustless uses unmodified apart from the API key and a fee cap — is Lightspark (api.lightspark.com), with a default operator pool run by Lightspark, Breez, and Flashnet (operator 0, Lightspark, acts as coordinator). The Breez API key authenticates SDK services; it does not change who the SSP is.
  • The SDK’s genuine unilateral-exit machinery exists — SparkWallet::unilateral_exit() — but it is a separate method that the breez-sdk-spark wrapper crate never calls (the only “unilateral” references in that crate are three doc-comments on a leaf-optimization tuning field). Consequently it is absent from the generated React Native bindings the source imports: the published BreezSdk class at 0.12.2 (the version resolved by source tag 2.0.2) exposes 41 methods, none of them exit-related (reproducible via npm pack @breeztech/breez-sdk-spark-react-native@0.12.2 and inspecting src/generated/breez_sdk_spark.ts). The same absence was confirmed at 0.12.3 (the version resolved by iOS tag 3.0.1 and main) and holds at 0.14.0 per the equivalent review of another Breez-SDK wallet under #947 — so even if the distributed APK’s embedded SDK build differs from the declared version (see the #156 note above), no nearby SDK version exposes a unilateral-exit call either.
  • Trustless’s own code never references unilateral exit (repo-wide grep: zero hits), and no Trustless-specific external recovery tool was found — the TrustlessWallet GitHub org has no analogue to BlitzWallet/spark-recover.

So if the Spark operator infrastructure went offline or refused to cooperate, a Trustless user could not exit their Lightning balance to L1 through anything the app or its SDK version exposes. The on-chain balance is unaffected by that scenario (§1/§3).

Summary

Trustless is a hybrid: its primary on-chain wallet meets the exclusive-control bar (local standard-path keys, local signing, Electrum data with custom-server support, seed importable anywhere), while its Lightning balance sits on the same cooperative-exit-only Spark integration that determined the custodial verdict for Wallet of Satoshi under the WoS precedent. Because the app markets that Lightning balance as “non-custodial” without clearly marking its custodial character, the product is classified custodial as a whole under WalletScrutiny’s written policy (see the verdict rationale in the Analysis section). The app’s own claims (“non-custodial Lightning,” “The developers of this app never have access to your funds and cannot retrieve them for you”) are accurate for the on-chain balance but overstate the Lightning side: withdrawing that balance requires the cooperation of the Spark Service Provider and operator infrastructure, and no unilateral fallback is reachable by users today.

Separately noted for a future reproducibility review: both of the repository’s closed issues concern reproducibility — #19 and #156 (the latter reporting 37 binary differences between the GitHub release APK and a rebuild of v2.0.2).

Product page updated by Pechen987 https://github.com/Pechen987, 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.

Share on Social Media