Grant Application - Hito Hardware Wallet - Zcash Cold Signing (Orchard)

Community Grants Applications
1

Hello Zcash Community,

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:

  • Offline singing for Orchard shielded transactions
  • Private keys remain fully isolated on device
  • Support for desktop and mobile workflows
  • Integration with lightwalletd / Zodl wallet
  • End-to-end flow: create → export → sign offline → broadcast

Why this matters

Zcash’s core value is private, but:

  • Shielded flows lack simple cold storage options
  • Users often rely on hot wallets for private transactions

This project enables practical, hardware-secure usage of shielded ZEC.

Execution overview

  • Firmware implementation for transaction parsing and signing
  • SKD + wallet integration
  • QA, regression testing, and documentation
  • Community beta testing before release

Milestone-based delivery (3-4 months), culminating in mainnet-ready offline singing.

Grant

  • Total requested: $50,000
  • Covers firmware, integration, QA, documentation, and beta

Status

  • Hardware already in production (5,000+ units)
  • Firmware stack active
  • Zcash integration scoped and ready to begin

Full proposal

Full grant application (milestones, deliverables, risks, budget): → Grant Application - Hito · Issue #280 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

Feedback

We would appreciate feedback from the community, especially on:

  • Orchard signing approach and compatibility
  • lightwalletd / wallet integration preferences
  • Testing and validation expectations
8 Likes
2

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?

3 Likes
3

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.

3 Likes
4

Architecture

1. Software / app architecture

The host app handles the heavy Zcash work:

  • transaction construction
  • lightwalletd / network interaction
  • Orchard proof generation
  • PCZT or equivalent signing package preparation
  • final transaction assembly and broadcast

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.

3 Likes
5

This seems actually pretty tight h/w wise.

3 Likes
6

Agreed - constraints are tight, esp around transaction size and parsing.

And we are not doing proving on-device - only parsing and singing, which keeps compute requirements bounded.

Our approach:

  • bounded / streaming parsing of the signing payload (no full buffering where possible)
  • early validation in Mileston 1 (no UI, focus on correctness + memory limits)
  • performance critical parts implemented in C (low-level crypto + parsing), with Rust for overall structure

On the UI side, we use a dynamic Slint-based approach with very low memory overhead, so UI does not compete with signing logic for the resources.

We will validate memory footprint and transaction size limits explicitly before moving to full integration.

2 Likes
7

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. :slight_smile:

2 Likes