Zcash community: Hello from KeepKey!

Zcash community: Hello from KeepKey!

Many of you know KeepKey as a long-running open-source hardware wallet. Since separating from ShapeShift, our team has rebuilt the firmware, desktop software, and device-management stack from the ground up. Implementation is led by Highlander — former lead at ShapeShift — alongside senior engineer Pastaghost, with illithics supporting coordination, documentation, and delivery tracking. That foundation gives us a practical path to Orchard signing on a physical KeepKey device, with private keys remaining on-device.

We have experimental firmware and software from a demo with Zcash Brasil:

https://www.youtube.com/watch?v=VyASii70ZLg

The experimental firmware demonstrated feasibility. This grant funds the work that turns a prototype into an auditable, shippable product: production hardening, mainnet validation, external audit remediation, and user-facing documentation.

1. Executive Summary
KeepKey is requesting $135,000 to complete, validate, remediate, and release Orchard-only shielded Zcash signing on physical KeepKey hardware, and to add a separately scoped public SDK integration example milestone beginning with Zingo.

The project adds Orchard signing under transaction version 5 while keeping the hardware-wallet model intact:

  • Private keys remain on-device

  • Transactions require physical user approval

  • The host never accesses private keys

The host constructs transactions and generates Halo2 proofs. The KeepKey device derives Orchard keys and nullifiers, computes the ZIP-244 signing digest, displays key transaction details, and signs only after user confirmation.

The grant funds core KeepKey implementation, physical-device validation, audit remediation, production release, user/developer documentation, and a dedicated $45,000 SDK integration example milestone.

Least Authority will audit the KeepKey Zcash signing implementation. The audit is being financed separately and is not included in this request. Release-blocking findings will be remediated before release, and the report will be public.

At completion, this gives Zcash another shielded cold-storage option, a publicly audited open-source implementation, and a practical path toward third-party wallet interoperability.

2. Problem and Proposed Solution

Shielded privacy is one of Zcash’s core strengths, but KeepKey currently supports only transparent Zcash transactions. This proposal upgrades an existing hardware wallet to support Orchard-only signing under transaction version 5, including Unified Address support and physical-device validation.

The project also includes a dedicated public SDK milestone. The goal is to give open-source wallet developers a reusable path for communicating with KeepKey during the Orchard signing flow.

3. Technical Scope

This project implements Orchard-only signing under transaction version 5 using a host/device model.

KeepKey Vault will:

  • Connect to lightwalletd

  • Select notes and construct transactions

  • Generate Halo2 proofs

  • Send structured signing requests to the device

  • Broadcast signed transactions

The KeepKey device will:

  • Derive Orchard keys using ZIP-32

  • Generate and display Unified Addresses

  • Derive nullifiers internally

  • Parse v5 signing requests with bounds enforcement

  • Compute the ZIP-244 signing digest

  • Display amount, network, fee, recipient summary, and change indicator

  • Sign only after user approval

The device does not:

  • Generate proofs

  • Verify zero-knowledge proofs

  • Maintain chain state

  • Construct transactions

Device-side review and digest computation reduce host-side tampering risk, but they do not eliminate user-deception risk.

4. Public SDK, Scope, and Risks

This proposal includes a dedicated public SDK milestone for software-wallet integration.

The goal is to produce a reusable integration path showing how third-party wallets can communicate with KeepKey during the Orchard signing flow. This work is broader than a one-off wallet integration: the deliverable is a public SDK, reference implementation, integration notes, and developer-facing documentation.

Acceptance, merge, or long-term maintenance by any third-party wallet project is not in scope.

Out of scope:

  • Sapling support

  • Legacy transaction formats and pools

  • Third-party wallet acceptance, merge, or long-term maintenance

Main risk controls:

  • ZIP-244 digest validation against reference implementations

  • On-device nullifier derivation

  • External audit of parsing, signing logic, and host/device boundary

  • Remediation capacity built into the budget

  • SDK work is milestone-separated so it can be reviewed independently from the core hardware signing release

5. Budget and Milestones

Total requested: $135,000

Milestone 1 — Core Implementation & Validation: $50,000

Timeline: up to 3 months

Deliverables: Orchard-capable firmware, KeepKey Vault host integration, physical-device signing flow, testnet Orchard transaction, test vectors, build artifacts, and auditor-facing documentation.

Verification: public testnet transaction and code available for review.

Milestone 2 — Audit Remediation & Production Release: $25,000

Timeline: approximately 1 month after audit findings are available

Deliverables: remediation of release-blocking issues identified during the Least Authority audit, updated firmware and Vault integration, regression testing of the remediated signing flow, production release artifacts, and a mainnet Orchard transaction signed using KeepKey.

Verification: public release artifacts, confirmed mainnet transaction, and public audit report or remediation summary showing that release-blocking findings were addressed.

Milestone 3 — User Safety & Documentation: $15,000

Timeline: 3–4 months

Deliverables: user documentation, user walkthroughs, developer reference materials, and safety materials explaining the Orchard signing flow and device-confirmation model.

Verification: public documentation, developer materials, and user-facing walkthroughs available.

*Milestone 4 — SDK and Wallet Integration Example: $45,000

Added based on community feedback

Timeline: 2–3 months

Deliverables: open-source software-wallet SDK for the KeepKey Orchard signing flow, reference integration using Zingo as the first target wallet, public pull request or public integration branch, integration notes, and developer-facing documentation showing how third-party wallets can communicate with KeepKey.

Verification: public SDK repository or module, working reference integration demonstration, public Zingo proof-of-concept branch or pull request, and developer documentation available for review.

Scope note: merge or acceptance by Zingolabs is not included in scope. The broader deliverable is the SDK and reusable integration path, not Zingo-specific maintenance.

Milestone Gating

Payments are milestone-gated. If a milestone is not completed, subsequent milestone payments are not requested.

We appreciate your consideration and welcome any questions.

– KeepKey Team

(Last edited 5/16. Added milestone based on feedback of a broader wallet ecosystem)

10 Likes

I had the pleasure of being present and closely following the entire process at the demo. I’m very happy to see this implementation happening. I’ve been testing KeepKey’s product for several years and have never had anything to complain about. Besides being an exclusive “derive on device” feature, I believe it can bring good results for both sides. I’m excited and supportive.

3 Likes

Hi, love to see KeepKey building support for Orchard! I have a few questions:

  • Is it possible to build+flash firmware ourselves to avoid supplychain risk?
  • Is it possible to enable SLIP-39/Shamir split wallets for Zcash? That’s a badly needed feature in the ecosystem and I think a valuable differentiator for your product.
4 Likes

Is it possible to build + flash firmware ourselves to avoid supply chain risk?

Yes! KeepKey has zero blobs or proprietary hardware by design. We maintain keepkey/keepkey-diy with a full parts list, and we’ve published videos of users taking the initiative to build devices themselves.

SLIP-39 / Shamir split wallets for Zcash

I would need to audit this further, but since Shamir is primarily a recovery and backup scheme, I believe we already support it at the firmware level. We have not yet implemented this in our GUI wallet because the UX of entering multiple sets of 24-word shares is fairly brutal.

That said, if this is a requested feature, it is absolutely doable.

4 Likes

Thank you for the proposal.

I tend to favor any good hardware wallet that can handle integration. In this case, if KeepKey offers integration with Zingo, that’s already a significant gain.

IMO: the ROI of fungibility is far greater than the price. Fungibility is a fundamental value, and making shielded pool/transactions grow in many ways is better, accessible, and safe on hardware wallets as much as we can is exactly how we deliver extra value to users without retaliation.

When evaluating grants, I always look at a team’s past work and longevity in the crypto space. KeepKey has consistently supported this idea and the Zcash ecosystem over the years.

Self-custody is still rare simply because hardware wallets are too expensive for the average user. Having an affordable, locally available option like KeepKey is crucial for driving global adoption.

3 key points that stand out to me:

  1. Showing their faces publicly and putting their reputations on the line tells me a lot about their commitment: https://www.youtube.com/watch?v=VyASii70ZLg
  2. They have been running since 2014, marking 12 years of solid history in the space: https://x.com/cryptokeepkey
  3. They had a proposal rejected previously, yet still worked over the last ˜5 months to make it happen now.
3 Likes