Zcash community: Hello from KeepKey!

[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)

(7.1.26)

Link to issue: Grant Application - KeepKey: Orchard Shielded Zcash Signing on Hardware + Zingo & ZODL Integrations · Issue #341 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

[E-zec]

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.

[nullcopy]

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.

[BitHighlander]

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.

[Michae2xl]

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.

[BitHighlander]

I wanted to give the community an update: today we released our Zcash emulator integration for KeepKey Vault.

keepkey(.)com/zcash

The point of releasing emulators like this is transparency. Developers, auditors, and AI-assisted reviewers can use Vault without owning a KeepKey device to exercise the full Zcash lifecycle — receive, shield, unshield, send, and verify the device screens — directly against the running emulator.

Our PoC includes on-device address derivation, on-device validation of shielded outputs and amounts, and clear-signing work intended to help prevent the device from blindly trusting the host.

This should show that, should this prop get funded, we will be able to release shielded support completely and not stop short of delivering all demanded functions needed to properly manage shielded funds as other projects have.

This is a large and ambitious step for KeepKey, and it would create the largest internal security audit surface we have ever taken on as a company. This PoC required writing crypto libraries in C, such as Sinsemilla, for protocol core components that were lifted from Rust and did not previously exist in C.

I also wanted to comment on AI.

AI has increased our productivity internally, but it has also increased the speed and scale of attacks against hardware wallets, wallets, and crypto infrastructure generally. This is happening now. Recent events in Zcash have shown how serious this is, as AI can surface exploit-level bugs and issues in some of the most hardened code that can affect us all directly.

Models like Mythos being gatekept and access being limited to large institutions while companies like ours (and 99pct of crypto) are left out are, in my opinion, one of the greatest threats our space has ever seen. It has led us to invest heavily in our own internal hardware — RTX Pros are not cheap — and spend the time required to train LLMs that are specific to our use cases and uncensored for the work we need to do just to catch up to what threat actors undoubtedly already have access to.

The work Venice is doing to bring high-end open models to users, and the work the OSS community is doing to push open models to the frontier, is the best way we can address these issues and we are following them closely.

We will be releasing more blogs posts directly on these issues, and the tools and methods we use, on our blog. Including some rather interesting findings and developments we have found in the space.

I would very much like to keep working on privacy and Zcash at KeepKey, and to finish this work that is such an important feature to our users.

[BitHighlander]

We’ve been asked several times for KeepKey usage metrics, so we want to be as transparent as we can while staying consistent with our privacy principles.

KeepKey does not track individualized user statistics. We do not group users, store wallet addresses, retain public-address data, or collect information that could be used to associate users with balances, activity, or asset holdings. We also do not embed traditional analytics tools into our wallet applications or infrastructure. This is intentional: for a hardware wallet, analytics can quickly become financial fingerprinting, and we believe that data should not exist in third-party or company logs in the first place. More background on that privacy model is available in KeepKey’s public privacy writeup. ([KeepKey][1]) That said, because this is a grant request, we want to provide the metrics we can responsibly share. We do maintain generalized traffic data for our coin and API infrastructure. This infrastructure is expensive to operate and is required for direct users of KeepKey software to fetch balances, broadcast transactions, and interact with supported chains.

At present, KeepKey wallet infrastructure is averaging roughly 150,000 requests per day. This figure represents aggregate infrastructure usage only; it is not tied to individual users, wallet addresses, balances, or behavioral profiles.

We also do not maintain “assets in orbit,” assets-under-management-style reporting, or any long-term generalized tracking of total assets held by KeepKey users. After KeepKey’s transition out of ShapeShift, we chose not to continue collecting this kind of wallet-level asset data.

KeepKey’s ShapeShift history is described here, including the 2017 acquisition by ShapeShift and the later separation into an independent company. ([KeepKey][2]) For historical context only: prior to the current KeepKey team’s stewardship, ShapeShift did track this type of aggregate asset data.

The last known figure from that period, in 2017, placed total assets held by KeepKey users at approximately $1.7 billion. We are sharing that number only as historical context, not as a current metric, because KeepKey no longer tracks user holdings in that manner.

In short: KeepKey can provide infrastructure-level usage metrics, but we intentionally cannot provide individualized user analytics, wallet clustering, address-based reporting, or current aggregate user asset balances. That limitation is not a lack of transparency; it is a direct result of the privacy-preserving architecture we believe a hardware wallet should uphold. —

[1]: keepkey(.)com/blog/hardware_wallet_s_and_user_privacy “Hardware Wallets and User Privacy | KeepKey Blog | KeepKey Hardware Wallet”

[2]: keepkey(.)com/shapeshift “Born from ShapeShift — Cross-Chain Swaps on KeepKey | KeepKey | KeepKey Hardware Wallet”

[ZCG]

Thank you for submitting your proposal. After careful consideration by the ZCG and a period for community comments on the forum, the committee has decided not to advance this proposal.

We genuinely appreciate the work and dedication you put into your application and hope you’ll continue to participate and contribute to the Zcash community.

[BitHighlander]

Thanks for your consideration.

After review and deliberation KeepKey has decided to fund the the initial release of Ironwood internally and move forward.

Matt

Lead @KeepKey