We are building Hito - a hardware-backed signing device for secure key management across crypto, identity, and delegated authority.
We have produced 5,000+ devices with a fully in-house stack (hardware, firmware, software), and now proposing to add Zcash cold signing support, focused on Orchard shielded transactions.
Proposal
We will implement a production-ready cold signing module for Zcash on Hito:
We do have cold signing solutions and coincidentally also had orchard support for ledger in the same family of wallets. But that was a couple years ago and Ledger did not want it despite it coming from one of the best developers in the Zcash ecosystem. Our current signing solution works on any commodity hardware. What architecture will you be using?Where will the specs and source code be hosted? What is the license?
The website is a bit light on hardware details. Zcash shielded protocol is famously heavy on computation. It’d be good to check that this is even possible first.
The Hito device is not expected yet to generate Orchard proofs.
We have native iOS / Android app forked from UnstoppableWallet with Hito wallet support, and we have developer version mini wallet to test firmware flows.
2. Firmware architecture
The firmware acts as an offline signer:
parse PCZT / signing package
derive required keys on-device
verify transaction structure and singing digest
display critical approval data to the user (with an option to see raw data)
produce Orchard spend authorization signatures
return signatures to the host
The main implementation challenge is not proving, but making sure the device can verify that the fields shown to the user correspond to the transaction being signed.
We use Rust Embedded, low-level cryptographic primitive in C library, and a patched Slint UI optimized for memory-constrained devices. We also have a desktop device simulator, which we plan to make open source as part of the work.
We use Zephyr as RTOS (real-time operating system) backed by Linux Foundation. The Zephyr source code linked to the firmware is under Apache 2.0.
3. Hardware architecture
We use Nordic nRF54LM20 with TEE / hardware-accelerated crypto / dedicated key management uint, paired with an EAL6+ certified secure element.
The goal is vendor-independent hardware security: no single vendor component should become the only trust anchor.
Hosting
Code and specs will be hosted publicly on Github.
Planned public components:
firmware Zcash module
SDK / host-device protocol
PCZT handling / singing spec
tests and test vectors
desktop simulator
documentation and integration examples
License
Firmware + SDK: MIT or Apache 2.0
Documentation: MIT / Creative Commons
We are open to aligning with ZCash ecosystem preferences if there is a strong recommendation.
The challenge is in the derivation of the sighash from the plaintext transaction. Without doing that, the hito device would be signing a “blank check” since a corrupted companion app could feed a malicious payload.
It should be fine on an nRF54LM20 but for the security hyperminded, note that the crypto operations will be running on an “insecure” CPU (Pallas isn’t supported in hardware).
This is like the Keystone which also pairs a regular CPU with a EAL6+ SE. The Ledgers have an advantage: Their SE is a CPU and runs the crypto, albeit very slowly. This is not an endorsement, just a FYI.
@hito at the most recent meeting, ZCG voted to approve this proposal. Congratulations!
To keep the community informed, ZCG requests that you provide monthly updates via the forum in this thread.
Please check your forum inbox for a direct message from FPF with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests.
We now have console-based offline singing workng across the simulator and devboard, with multiple transaction types signed and validated.
The implementation covers Transparent, Sapling, Orchard parsing/singing, PCZT handling, end-to-end offline singing flow, and regression tests for core signing logic.
Additional validation beyond the original milestone scope has also been completed: a first signed Zcash testnet transaction was successfully broadcast.
One real Orchard spend/output and one zero-value/dummy Orchard action were handled correctly.
The signed transaction was accepted by the Zcash testnet network.
Current status against milestone objectives:
Offline signing demonstrated in a controlled setup: complete
Valid signed transaction produced: complete
Regression tests passing across simulator/devboard flows: complete
Correct handling of PCZT transaction structures: complete
Broadcast not required by the milestone, but successfully demonstrated on testnet
Implementation Notes
The Milestone 1 implementation targets the Hito hardware development board running Zephyr RTOS.
The signing implementation is built on top of our cross-platform libcrypt0 cryptographic primitives library, which provides the low-level cryptographic building blocks shared between the desktop simulator and embedded firmware. This allows the same signing logic to be executed in both environments while minimizing platform-specific code.
The firmware currently runs with:
Zephyr RTOS
Heap: 61 KiB
Stack: 22 KiB
Validation was performed in three stages:
Desktop simulator regression tests.
Hardware devboard signing using the same signing implementation.
Sucessfull singing and broadcast of a Zcash testnet transaction using zcash-devtool.
This milestone focuses on the sinning engine and transaction correctness. The production user interface and higher-level wallet functionality are outside the scope of this milestone.
Progress Update: UI-Based Transaction Signing on Hardware
Another milestone completed.
We’ve successfully generated a Zcash transaction using our Android app (an Unstoppable Wallet fork with Hito hardware wallet support) and signed it on the hardware wallet running on our development board.
The transaction signing flow is now running end-to-end on the development board with a working UI. The device is able to display transaction details, guide the user through the confirmation flow, and produce valid signatures entirely on-device.
Below are a couple of photos of the current signing flow running on the hardware.
The UI is till under development, and the core signing flow is now integrated with the firmware and running on real hardware. We’ll continue refining the user experience while expanding protocol support and improving robustness.
As always, feedback is welcome.
P.S. The UI is implemented in Rust Embedded (Zephyr) using a patched version of the Slint UI.
Demo video - Zcash signing flow running on Hito hardware wallet dev board with embedded UI paired with android app - fork of Unstoppable wallet with hito support
We’ve completed Milestone 2 of the Hito Zcash hardware wallet grant.
This milestone builds on the console-based signing engine from Milestone 1 by adding a complete user-facing workflow. Users can now create a Zcash transaction in an Android wallet, transfer it to the Hito device, review and sign it completely offline, and import the signed transaction back into the wallet.
Highlights:
Android UI for Zcash hardware-wallet accounts (based on our fork of Unstoppable Wallet).
Hardware account onboarding using the Unified Full Viewing Key (UFVK), Unified Address, ZIP 32 seed fingerprint, and network.
Transaction review on the Hito device, including recipients, amounts, fee, change, network, and transaction type.
Support for Transparent, Sapling, and Orchard transactions.
BLE transport with BBQr QR export of the signed PCZT.
Additional integration and regression testing for the complete signing flow.
The Android application never receives the hardware wallet’s seed or private spending keys. Signing remains fully offline on the Hito device.
Milestone 2 transforms the signing engine delivered in Milestone 1 into a practical hardware-wallet experience that can be used without any console interaction.
We just successfully submitted our first real Orchard-Ironwood Zcash transaction signed on a physical Hito device.
The transaction went through the complete hardware-wallet flow: create the transaction in the Android wallet → send it to Hito → review and sign offline on the device → return it to the wallet → submit it to the testnet
network.
Update: we successfully completed a series of mainnet transactions using real Hito hardware and the Andoird app:
Ironwood → Ironwood
Ironwood → Transparent
The full flow is working end-to-end: create the transaction in the Android wallet → transfer it to Hito → review and sign offline on the physical device → return it to the wallet → broadcast to mainnet.
Ironwood support was not part of the original scope for this milestone, and we added it to keep up with the current Zcash network.
Milestone 3 - Network Integration + Production Release
Milestone 3 is complete
We have integrated the Hito firmware with our Android fork of Unstoppable Wallet and completed the full end-to-end Zcash hardware wallet flow:
create transaction → transfer to Hito → review and sign offline on physical hardware → return signed transaction → combine with proofs → broadcast to the Zcash network
We successfully tested the following transaction flows on both testnet and mainnet:
Orchard → Ironwood
Ironwood → Ironwood
Transparent → Ironwood
Ironwood → Transparent
The original milestone required Orchard support. During development, the Zcash network transitioned to Ironwood, so we additionally implemented Ironwood support to keep the integration compatible with the current network.
The resulting implementation includes:
Hito Zcash signing firmware running on physical hardware
Android Unstoppable Wallet fork with Hito hardware-wallet support
Network integration through the Android wallet
Offline transaction review and signing
Signed transaction return and network broadcast
Orchard and Ironwood support
Repeatable testnet and mainnet transactions
Production firmware/application builds
What is not finished yet
While the complete flow is operational and we have successfully tested it on mainnet, we do not consider testing and production hardening finished yet.
Testing so far covered our Android Unstoppable Wallet fork, and the transaction flows. The implementation has not yet undergone an independent security audit or exhausive testing.
We also identified performance limitations in our current Slint-based device UI. The signing functionality works, but further UI refactoring and polishing are needed to improve responsiveness and address minor UX issues such as missing progressbars.
We consider these appropriate subjects for a follow-up testing and security hardening phase rather than blockers for the network-integration milestone.
Our next step is therefore broader testing, UI/firmware stablization, and an independent security audit.
