Nighthawk Wallet Design & Development Grant

With the release of Nighthawk iOS v1.21 on App Store & Nighthawk Android v1.0.20 on Play Store, we have successfully reached the first Milestone. We would like to share our achievements, which are well received by end users on both Android & iPhone.

Screen Shot 2021-07-13 at 7.02.38 PM

The status will be updated regularly and published at

Additionally, we:

  • Resolved several user support requests via Emails, DMs and GitHub issues.
  • Proactively participated in mobile design discussions for NU5 & Unified Address UX with ECC.
  • Engaged with end users, product walkthrough and noted shortcomings to improve upon.
  • Obtained necessary hardware & software towards meeting milestone deliverables.
  • Renewed the App Store Developer subscription with Apple.
  • Updated the app landing page at
  • Regularly attended development meetings with the LCWG.
  • Setup continuous integration via Bitrise and enabled test-net build variants for ease of testing.
  • Transitioned from relying on existing lightwalletd server to with 0 service interruption for our end users.
  • Fixed a vulnerability reported to us via our Disclosure Policy.
  • Reported a vulnerability upstream and acted immediately releasing a fix to prod.
  • Followed the strict no logging/tracking policy.
  • Kept app dependencies updated with the latest fixes from ECC & native Apple/Android eco-system.

Android specific:

  • Enabled language configuration to prepare for auto-translations to multiple languages.
  • Increased number of supported devices for Nighthawk on Android to 14,579 devices(per Play Console) with minimum supported version of API 23/Android 6.0
  • Focussed on improving layouts & accessibility for supporting a broad variety of form-factors.
  • Enabled screen density configuration to generate optimized APKs for each screen density.
  • Switched to ABI configuration for releases instead of APKs for a smaller app download for users by removing the libraries of the ABIs their device will not load.
  • Reduced app download size to ~9MB after stripping out un-necessary Play Services components, also preparing the build towards a F-Droid release.

Developer community related updates:

  • Engaged with contributors and rewarded them for their contributions from our consulting budget.
  • Intro with ARTI developers and plan to provide them with mobile device requirements for running Tor by default on thin clients.
  • Attended Google I/O 2021 & Apple WWDC21 to keep up to date with the latest APIs, cryptography & security related updates on the Android & iOS platform.

Zcash users feature demands which we will R&D on as per bandwidth:

  • Passcode/Pin protected app start.
  • Contacts management with Z-addresses.
  • Deep linking for interacting with ZECpages.

Things to improve on:

  • Provide updates on Zcash Forums: As per the grant, we promised to post updates following every Milestone on Zcash Forums, especially after an observation of the forum activity slowing down. So we focussed on connecting with the end users directly for updates and troubleshooting. In the future, we will try to post updates to the forum alongside our alternate channels.
  • Investigate optimizing of sync times while maintaining maximum privacy & reducing information leakage. As for the scanning optimizations, once the faster community algorithms are verified and gotten thumbs up from @str4d , we can have those pulled in to Nighthawk for all the efficiency gains.The priority for the next milestone is still NU5 compatibility.
  • Improve regression testing to stop vulnerabilities from seeping in to production versions.

We thank @ZcashGrants for funding us and believing in our vision to ship Nighthawk Wallet on App Store, Play Store & soon F-Droid Store with regular updates.


Nighthawk Wallet on Android v1.0.20 is live on the Play Store

  • A whole better Nighthawk with T-address support + Auto-Shielding of funds after Transparent funds cross 1 ZEC.
  • Sending of ZEC is possible from Z-address only for preserving privacy.
  • Wallet History gets a new look too!

T-address → Z-address Shielding in action Nighthawk Android v1.0.20 - Album on Imgur


With the delay in NU5 on main-net, Nighthawk Wallet team would need to adjust the Milestone and deliverables. As promised in our last update, we have been maintaining the live status of development at

In April this year, in line with the prospective July/August launch of NU5, we had planned the launch for UAs to be undertaken in Milestone 2/3, but it is clear now that only the Test-net will be available in Q4 2021 with Main-net launch in Q1 2022. While this delay would give us extra time to refine on UA support and testing before the Q1 readiness, but it will delay our final deliverable flowing in to Q1 22’.

With the extra cycles available in Q4, I have requested @ZcashGrants to review us undertake working on much needed areas to improve on the wallet:

  1. Improve automated & manual testing across various devices and
  2. Adding easy ZEC purchase support. I have started communication with which can process KYC & Payments so the purchases will be taken care by them, supporting many countries, but not US per their policy :frowning:
  3. Additionally, we can focus on developing the designs with Matt for faster iterations and implementation starting with Android. iOS app redesign update might take longer as the Swift UI framework is very new and it would require diligent coding to bring Matt’s designs to life.

Additionally, I would like to share a short retro for Milestone 2:

What went well

  • F-Droid launch with no anti-features, setting up automated release publishing. Great feedback from the Unlocked Droid community to have a dedicated, Google-free wallet for Zcash.
  • We even got a mention by a Professor from Germany when comparing privacy coins.

And Naomi Brockwell’s feature on Zcash!

  • Purchase of devices & computers for the team to improve security when developing software and improve debugging.
  • Shipped a bonus feature on Android to export wallet seed words to a password protected PDF for easy backup.
  • Shipped Android URI DeepLink & QR code scan for easy of UX when interacting with ZecPages or ZIP-321 compatible services.
  • Fixed test-net variant breakage in zcash-android-wallet-sdk repo upstream.
  • Increase in testing and review for shipping bug free native apps.
  • Got introduced to a research opportunity of building a privacy preserving retrieval of transaction info, this is fresh research and sounds very promising for the future of privacy in light clients.
  • Reviewing possibility of Thorchain integration in Nighthawk wallet for easy to use swaps.
  • With several bug fixes and support for Android 12 & iOS 15, our users are happier, require less support - we went from 4-5 support requests per week in July to 0/1 per week at the end of September while app downloads keep increasing beyond 1000 for both Google Play & Apple App Store each. Nighthawk users contact us via a combination of twitter, protonmail & z2z messages.
  • Take active part in code reviews of upstream wallet & SDK repos.
  • The bi-weekly Native Mobile Light Client Working Group calls have been going well with transparent updates available at (Thanks to following Hudson’s model from ETH cat herders calls)

What didn’t go well

  • Both iOS devs were down with COVID-19 causing a slippage of feature deliverables of Deep Linking/QR code scan & PIN code for app entry for Nighthawk on iPhone. These features were successfully shipped on the Android version to both Play Store & F-Droid.
  • Delays in the fast syncing algorithm integration - we are in close contact with ECC who are exploring an optimal solution for faster sync.
  • Translations work is delayed to Milestone 3 as the Lingohub rates for languages we plan to support increased by 3 times, which was out of our budget and not practical as the service package is a monthly payment in to perpetuity. We are now in the process of shifting to using platform for crowdsourced translations.
  • Flexa SDK integration work is also on a back burner as Flexa team is focussing on their own app and roadmap while delaying the release of their Spend SDK.

Thanks for the update. Btw, was this feature reviewed by a security expert?

AFAIK, pdf security isn’t very good and there are pdf password crackers that claim they can break it in seconds.

1 Like

What’s the time period for the 1000+ downloads of Nighthawk wallet?

True, PDF security is weak generally, hence we chose integrating iText Core 7 which makes libraries meeting Digital signature standards for PDF encryption iText 7 Core: an open-source PDF development library for Java and .NET.

It still creates pdf and these aren’t very secure, are they?

Let us know if you can crack the password protected PDFs generated via Nighthawk (via our Disclosure Policy

And maybe even contribute to the public upstream repo: GitHub - itext/itext7: iText 7 for Java represents the next level of SDKs for developers that want to take advantage of the benefits PDF can bring. Equipped with a better document engine, high and low-level programming capabilities and the ability to create, edit and enhance PDF documents, iText 7 can be a boon to nearly every workflow.

Hey, it’s not about iText 7. It creates encrypted PDF but encrypted PDF aren’t very secure.

I’m not a security expert, but maybe you should consult one? Maybe @daira @str4d ?

AFAIK, pdf encryption is good as long as the passwords are good but they don’t do key stretching to slow down brute force attacks.

This delay pushes out the planned implementation for Unified Addresses support in @NighthawkWallet further than anticipated. I am happy to see the release plan mature towards a well aligned release of NU5 + Halo Arc, which enables official Zcash SDK users and partners to support NU5 with verified code along with the protocol upgrade taking effect.

As brought up in the monthly update, contributors to Nighthawk Wallet are working with researchers to develop a Proof of Concept with a novel approach to sync transaction data between light clients and Zcash block server. This work will focus on reducing possible information leakage via lightwalletd and improving sync times for a better end user experience for Nighthawk users. We might be able to target the demo of this improvement along with the NU5 launch.


To clarify, how was iText 7 acquired? It would seem Nighthawk Wallet either is currently in violation of its licensing terms (AGPL) or not actively OSS.

As for security, it appears to use a 160-bit MD5 hash of the owner password to encrypt the user password into a checksum. The owner and user passwords seem to be frequently referred to as equivalent in general use and that is the case with Nighthawk wallet. Due to the lack of salting, that enables precomputation with ease, yet I couldn’t comment on how many such tables exist nor their scope. There does also appear to be software utilizing GPUs available to break keys yet I haven’t downloaded it to try.

iText7 is licensed as AGPL/Commercial Software. GitHub - itext/itext7: iText 7 for Java represents the next level of SDKs for developers that want to take advantage of the benefits PDF can bring. Equipped with a better document engine, high and low-level programming capabilities and the ability to create, edit and enhance PDF documents, iText 7 can be a boon to nearly every workflow.

Since Nighthawk has not modified the AGPL licensed iText7 library and is merely using it in binary form, “as-is”, the library doesn’t have to do anything other than improving the app and is fully compatible with Nighthawk Wallet. The wallet app is able to function without using the iText7’s features which are only used when a user decides to export a password-protected PDF.

The intention of having a password-protected PDF backup of the seed words is simply a feature to be used by the individual when securely backing up & transferring the seed words via digital media format. The primary suggestion(as present in the app) to take a backup of seed words is to write them down on a piece of paper.

1 Like

Right, except AGPL is a propagating license, just like GPL. Because Nighthawk wallet links with it, it must also be AGPL, yet Nighthawk is currently licensed as Apache 2.0. That’s why I said Nighthawk would be in violation of its licensing terms.

Section 5 (source) has the following quotes:
“You may convey a work based on the Program”
" * c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it."

Despite you using iText7 as a compiled JAR (presumably), it’s directly linked into your app which has the modern interpretation of the GPL consider your work derivative. You also are conveying source (Nighthawk) based on iText7 (as you are conveying source based on the “Program”, and the license doesn’t require it to be based on the “Program’s source”). If you had sandboxed it in an isolated app, solely that app would be AGPL, yet the direct linkage is generally considered to be pretty damning. You could get an exception, yet that exception (if limited to the group behind Nighthawk) could void Nighthawk as an OSS project due to the inability to fork off from it without relicensing (it may be legal for someone to fork Apache 2.0 work and relicense as AGPL without permission? I’m not entirely sure as AGPL should be more restrictive and therefore still honor Apache 2.0 but… it’s just a complete and utter mess to discuss).

IANAL. You should absolutely get a lawyer to review this. I wouldn’t touch the Nighthawk codebase, personally, with a ten foot stick until a lawyer confirms the legality of this. You can say iText 7 has yet to complain so you don’t care yet that’s really not a healthy solution (as it means iText 7 has the power to remove your app at any time, leaving you to fight them while the DMCA claim is active, potentially leading to a lawsuit in their jurisdiction).

I’ll also note your app, despite providing a UI, doesn’t appear to have any copyright statements in it.
" * d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so."
I don’t believe iText 7, a library, has UIs so that exemption shouldn’t apply, but I could be wrong as I haven’t worked with iText 7. My main focus is on the fact that Nighthawk doesn’t display any legal notices AFAICT. It seems to be the main page, an info button linking to Zcash, a ‘profile’ page (which has a box saying “Nighthawk” + version yet tapping it doesn’t expand it for more info), and settings, all without copyright statements. This may have issues for other libraries you use if they’re BSD-3/GPL.

EDIT: For further reading reference:

licensing - AGPL - what you can do and what you can't - Software Engineering Stack Exchange ← Says your work must be AGPL no matter what.

licensing - Use of Unmodified AGPLv3 lib - am I AGPL too? - Software Engineering Stack Exchange ← Says your work must be AGPL unless the AGPL code is sandboxed in another binary (as GPL code generally is when dealing with these problems). The first link contradicts that by saying even that isn’t enough, as the AGPL was intended to avoid web based license exploits (you’re never distributing the app, and therefore having users who you’re responsible to under these licenses, if you’re solely distributing a website which makes POST requests to your app). I believe as long as you still communicate the AGPL licensing of the other binary in your non-AGPL app, you can have a non-AGPL app.

The best reference may be Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation which seems to say it’s okay for Nighthawk itself to be Apache 2.0 (as it’s GPLv3 compatible) AS LONG AS it’s also licensed as GPLv3 and the sum product is released as a GPL binary (in contradiction to some of my commentary and parts of these other links). The distinction is you’re not currently releasing it as a GPL binary (see comments on copyright inclusion).

Various Licenses and Comments about Them - GNU Project - Free Software Foundation and the AGPL section 13 seem to confirm this.

It’s all a mess. This is why I’d get a lawyer to review this and give you a statement you can have ready for these discussions.


Luke, Thanks for sharing all your concerns.

The iText 7’s AGPL was carefully reviewed and discussed with my friends at FSF before adding it as a feature enabler for the Android client app. Additionally, developers contributing to Nighthawk have worked with Black Duck Software and are experienced with complex license structures. As noted earlier, Nighthawk does not provide the web interface to a program running remotely to an internet-facing customer to process a PDF, and uses an unmodified binary of the library for an optional feature that can be taken out by anyone forking the project. AGPL primarily deals with network-enabled web service programs. iText7 offers binaries that are usable in web services and end clients as well. It is fully compatible with Nighthawk.

The new app designs have an About screen with licenses planned.

The integration is straightforward and not “all a mess” as alluded to by your comments. I would still make a point to contact iText7 sales to revisit any changes to newer versions of the library. And I would be open to connecting with lawyers to review the license as well if the funding can be arranged for the same. Rest assured, Nighthawk Wallet is aiming to be the least dependent on any network services that might result in information leaks.

The AGPL was expanded to cover that scenario (network services) as it was an effective loophole in the GPL. That is not the only scenario it handles however, and it generally acts like the GPL (just also handling that scenario). I acknowledge that isn’t relevant here and didn’t make any part of my commentary predicated on a belief Nighthawk was communicating with iText 7 over the internet.

The GNU FAQ writings I linked seem to state your app binary must be GPL licensed, as I covered. If you’ve confirmed with lawyers that your app isn’t a derivative work (despite the authors of the license in question stating that your app would be as it links with the library and that’s sufficient to be derivative, regardless of modification to the work), or that those license requirements otherwise don’t apply, then that’s that. IANAL.

I would posit contacting their sales team means nothing. You’d either want to contact your lawyers or their lawyers. If you contact their sales team and get permission for your group, that wouldn’t extend to forks, hence one of the reasons I said it’s a mess.

1 Like

Thanks for bringing this up @kayabaNerve. I’m not a lawyer but it is my strong belief this would be in violation of the AGPL license. I’d even go so far as to say I wouldn’t feel comfortable include the library even if a lawyer told me I could (without a negotiated license).

Even if I’m wrong about the AGPL it seems clear to me from their README that letting people use this library for free in their non-agpl commercial products is not what is intended.

iText 7 is dual licensed as AGPL/Commercial software.

AGPL is a free / open source software license.

This doesn’t mean the software is gratis!

Buying a license is mandatory as soon as you develop commercial activities distributing the iText software inside your product or deploying it on a network without disclosing the source code of your own applications under the AGPL license.

EDIT: Personally I probably wouldn’t bother engaging a lawyer on this. I’d be either investigating licensing costs or removing it.

EDIT 2: I felt the need to 2nd this concern because the last thing I want ZCG funding is lawyers when it could have been prevented.

EDIT 3: If anyone is having trouble following this but wants to learn more I recommend you read up on LGPL (Lesser GPL). It was specifically created to allow scenarios similar to this. Knowing that LGPL was created to allow scenarios like this helps in understanding what GPL (and AGPL) doesn’t allow.


UPDATE: The problem pdf lib was replaced with an Apache License 2.0 one.
Thanks to @kayabaNerve & @GGuy for the inputs.


How are we looking on these efforts?
There haven’t been any updates in a couple months from either Nighthawk or ThorChain regards to the integration project
Tweets with replies by THORChain (@THORChain) / Twitter

I see some updates here :slight_smile:

(Nighthawk provides the THORchain updates)