Hi all,
This is my application to the Q4 2026 Coinholder-Directed Retroactive Grants round. GitHub issue: Retroactive Grant Application - Open-Source Zcash Hardware-Wallet SDK · Issue #123 · Financial-Privacy-Foundation/ZcashCoinholderGrantsProgram · GitHub
In one paragraph. Two open-source components for Zcash shielded (Orchard and Ironwood) hardware signing: a device-agnostic Rust SDK for the host side, and a dependency-free C library for the device side that checks and signs, tested against librustzcash. The library is built for small microcontrollers: no heap, no dependencies, at most 512 bytes of stack per function, and the whole wallet app built on it fits a Flipper Zero’s ~134 KB of available heap. FlipZcash, a Flipper Zero firmware built on both, is the working example. I am asking $16,875 for the completed work.
This is a resubmission. The earlier version (issue #28, $40,000) was rejected in Q3. I read that as a clear answer. What changed:
- The amount: USD 16,875, with an hours-based budget (225 h at USD 75/h).
- The length: the old application was far too long. This one fits on a page; the detail is in the repositories.
- The objection on the old thread. @hanh’s last point there was that the companion app cannot be trusted (“stop thinking piece by piece. Nothing it says can be trusted.”). He was right, and my reply of 28 May — that only the proof was still trusted — was wrong. Before resubmitting I ran an adversarial review of the whole stack with AI tooling, including a pass playing a fully malicious host and a fuzzer comparing what the screen showed with what was signed. It found real problems in the code I had called complete in #28, including a way for the host to hide an arbitrary fee behind a normal-looking one (the overspend hanh warned about), and change outputs the device could not tell from an attacker’s. Those are fixed, the library ones each with a regression test. The device now decides by itself which outputs are change, re-encrypts every output that carries value, and computes the fee and the total leaving the wallet from data bound by the signature. The issue has a table of what it checks and, just as important, what it does not.
What I am not claiming. This is not a consumer wallet and you should not keep savings on a Flipper. There is no secure element, no third-party audit, and no vendor has integrated the library yet. A 5-digit PIN protecting an SD card can be brute-forced offline. Transparent inputs are not supported. The limitations section of the issue lists all of this.
The current code signed a testnet payment on my Flipper Zero today, after NU7: 30f35b3a…808195 (block 4,616,057). The device showed the payment with its full address and memo, recognised the change as its own, and asked me to confirm the totals before signing.
A request to anyone who builds wallets or firmware. The program asks that completed work be checked by the people it is meant for. If you have ten minutes, this needs no hardware:
git clone https://github.com/wh00hw/libzcash-ironwood-c && cd libzcash-ironwood-c
git checkout c2f09bf
cmake -B build -DSTACK_ANALYSIS=ON && cmake --build build -j
(cd build && ctest --output-on-failure) # expect 21/21
./scripts/check_stack.sh build # expect PASSED
A reply here saying what you ran and what happened, including “it failed on my machine”, is worth more to this application than anything I can write. If you own a Flipper Zero, the firmware build is in the FlipZcash README.
I will answer questions in this thread throughout the review period.