Wallet Logo

Zap: Bitcoin Lightning Wallet

latest release: Varies with device last analysed  22nd December 2020
Reproducible when tested


Our last analysis is based on data found in their Google Play description and their website and their source repository. We discuss issues with the provider here.
details below 

Older reviews (show 0 of 1 reproducible)

Help spread awareness for build reproducibility

Please follow Zap: Bitcoin Lightning Wallet and thank them for being reproducible via their Twitter!


The following Analysis is not a full code review! We plan to make code reviews available in the future but even then it will never be a stamp of approval but rather a list of incidents and questionable coding practice. Nasa sends probes to space that crash due to software bugs despite a huge budget and stringent scrutiny.

Do your own research!

Try out searching for "lost bitcoins", "stole my money" or "scammers" together with the wallet's name, even if you think the wallet is generally trustworthy. For all the bigger wallets you will find accusations. Make sure you understand why they were made and if you are comfortable with the provider's reaction.

The Analysis

This app is a remote control for lnd, the lightning network daemon. As such it is not exactly a wallet in the sense of many other wallets here as the lnd connected to, also has control over the funds but in a setup where you connect to your own lnd, Zap gets into the position of being able to steal your funds. If you have strong objections with the classification as a wallet, please open an issue on our GitLab.

This app was not reproducible but the provider recently let us know that version 0.3.8 would be reproducible.

Today we got the 0.3.8 update from Google Play, too, so here is another attempt at reproducing Zap:

$ cd /tmp
$ git clone https://github.com/LN-Zap/zap-android
$ cd zap-android/
$ git checkout v0.3.8-beta
$ docker run --rm -it --volume=$PWD:/mnt --workdir /mnt mreichelt/android:latest bash
root@20b0f7c2e660:/mnt# ./gradlew assembleRelease
29 actionable tasks: 29 executed
root@20b0f7c2e660:/mnt# mv app/build/outputs/apk/release/zap-android-0.3.8-beta* .
root@20b0f7c2e660:/mnt# exit
$ cd ..
$ apktool d -o fromBuild zap-android/zap-android-0.3.8-beta\(26\)-release-unsigned.apk 
$ apktool d -o fromGoogle path/to/Zap\ 0.3.8-beta\ \(zapsolutions.zap\).apk 
$ diff --brief --recursive fromBuild/ fromGoogle/
Files fromBuild/apktool.yml and fromGoogle/apktool.yml differ
Only in fromGoogle/original/META-INF: CERT.RSA
Only in fromGoogle/original/META-INF: CERT.SF
Files fromBuild/original/META-INF/MANIFEST.MF and fromGoogle/original/META-INF/MANIFEST.MF differ

and that’s what we want to see to give the app the verdict reproducible.

Verdict Explained

Reproducible when tested
At the time of this analysis, the app on Google Play was reproducible from the code provided by the developers!

The app can be independently verified. If the provider puts your funds at risk on purpose or by accident, security researchers can see this if they care to look. It also means that inside the company engineers can verify that the release manager is releasing the app based on code known to all engineers on the team. A scammer would have to work under the potential eyes of security researchers. He would have to take more effort in hiding any exploit.

"Reproducible" does not mean "verified". There is good reason to believe that security researchers as of today would not detect very blatant backdoors in the public source code before it gets exploited, much less if the attacker takes moderate efforts to hide it.

To understand why some lines of difference are ok and others not one has to consider how app signing works. Android supports currently 3 signing schemes and in version 1 signing the signature is put inside the application file. As the tester must not have the release signing key, those files necessarily are missing or differ from the version on Google Play. The file "apktool.yml" was never part of the app and is generated by the analysis tool "apktool".